shmem: improvements #16
Conversation
|
Is it backward compatible with old implementation? Or is there a way to detect if a client uses old version and switch implementation in runtime? |
Maxython
force-pushed
the
shmem-improvements
branch
2 times, most recently
from
92b148b to
dce2c1a
Compare
The possibility of remote interaction with shmem is implemented, i.e. the shmem socket is multifunctional and can not only send data, but also start an action and update shmem data. This allows you to implement shmem actions close to the original system V shared memory from Linux. For example: - Delete shmem if the process is not native - Count the number of attached and process ids - Filter shmget actions according to flags (i.e. shmget now understands the IPC_CREAT and IPC_EXCL flags) Also added new tests to check all these functionalities.
Maxython
force-pushed
the
shmem-improvements
branch
from
dce2c1a to
7860a0d
Compare
No, the old version of libandroid-shmem is not compatible with the new one.
I only have an idea how to make the new libandroid-shmem detect old shm (libandroid-shmem) and configure itself for them to work with it. But this means that the functionality of such shm will be limited (i.e. there will be no new features like in the new libandroid-shmem) and such implementation of compatibility will greatly complicate shm processing. |
Maxython
force-pushed
the
shmem-improvements
branch
5 times, most recently
from
a27477b to
e55e679
Compare
|
For testing, changes from PR #17 were added, but with some modifications. |
Maxython
force-pushed
the
shmem-improvements
branch
from
e55e679 to
cdcf597
Compare
|
|
||
| static int ashv_fork_function() | ||
| { | ||
| pid_t p = fork(); |
There was a problem hiding this comment.
Forked processes inherit all parent's opened file descriptors, the copy of the whole memory and other data which may be a bit resource-wasting in the case if you load this code in some "heavy" or resource extensive program. I see two solutions for this:
I. vfork+exec to spawn some process (global android-shmem daemon?) without copying all process-related resources and executing some minimalistic background daemon. You can flock to avoid concurrency during daemon execution and pipe/socketpair for sync (since you do not wait for daemon to be finished but you need to wait until it start its mainloop.
So it will be like
- Trying to connect.
- If connection was refused or socket is not found you do
flockto make sure other process does not try to spawn process (with nocloexecflag). - You create socketpair in parent process.
- You spawn process with
vfork+exec. Parent process closes waits for pipe/socket closing withpoll. - Child process (global android-shmem daemon binary?) spawns global socket for connections, closes
flockfile and pipe-socket created for sync. - Parent process connects to newly created socket and does what it want to do with the socket.
II. You can do vfork to not create copy of all process-created resources and do _exit to not trigger any atexit stuff, but I am not so sure how to avoid blocking parent thread. Not recommended.
There was a problem hiding this comment.
I don't think vfork is a good solution to this problem, because it requires running some program (binary) or exiting the vfork process. I think clone could solve this problem, because it has flexible settings regarding COW (copy-on-write) mechanism.
3 participants
The possibility of remote interaction with shmem is implemented, i.e. the shmem socket is multifunctional and can not only send data, but also start an action and update shmem data. This allows you to implement shmem actions close to the original system V shared memory from Linux. For example: