You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The C destructor function of the SharedMemory object calls shm_unlink(...) and sem_unlink(..).
As an effect it is not possible to open a named shared memory region after a destructor has been called (until eventually all processes using the resource terminate and the memory region gets finally de-allocated and its contents get destroyed).
This is a problem if it needs to be still possible to open a memory region even after one process using the resource terminated.
Common use-case: One (main) process keeps running while other processes which "connect" to the main process are fired up and terminate as needed.
The idea is adding an option to the SharedMemory blocks which prevents unlinking. The default value of cleanup = true results in the current behavior.
In a setup of several memory sharing processes, at least one process needs a block which specifies cleanup=true, otherwise shm_unlink(...) and sem_unlink(..) will never be called.
The option has no effect on Windows which (to my understanding) doesn't have a similar issue and simply cleans up after there is no reference left on the file mapping handle or the semaphore handle (or is there an issue, too?).
The text was updated successfully, but these errors were encountered:
This is Linux specific.
The C destructor function of the SharedMemory object calls
shm_unlink(...)
andsem_unlink(..)
.As an effect it is not possible to open a named shared memory region after a destructor has been called (until eventually all processes using the resource terminate and the memory region gets finally de-allocated and its contents get destroyed).
This is a problem if it needs to be still possible to open a memory region even after one process using the resource terminated.
Common use-case: One (main) process keeps running while other processes which "connect" to the main process are fired up and terminate as needed.
The idea is adding an option to the SharedMemory blocks which prevents unlinking. The default value of
cleanup = true
results in the current behavior.In a setup of several memory sharing processes, at least one process needs a block which specifies
cleanup=true
, otherwiseshm_unlink(...)
andsem_unlink(..)
will never be called.The option has no effect on Windows which (to my understanding) doesn't have a similar issue and simply cleans up after there is no reference left on the file mapping handle or the semaphore handle (or is there an issue, too?).
The text was updated successfully, but these errors were encountered: