El 09/05/2024 a las 19:56, Niall Douglas via Boost-users escribió:
On 09/05/2024 18:48, Joaquin M López Muñoz via Boost-users wrote:
I see. boost::flyweight::intermodule_holder is a mere wrapper over boost::interprocess::ipcdetail::intermodule_singleton, so I guess Ion Gaztañaga is more qualified than me to answer this. From a cursory look at the relevant Boost.Interprocess code, seems like locking is based on a unique temporary filesystem path that uses both the process ID and its start time:
https://github.com/boostorg/interprocess/blob/develop/include/boost/interpro... https://github.com/boostorg/interprocess/blob/develop/include/boost/interpro...
So, the code should be robust against dangling locks because the combination (PID, start time) won't ever repeat. Maybe you can debug your program and try to isolate the actual path generated for the offending scenario?
If the shared memory naming pattern were changed to something else to preserve backwards compatibility, if each user of the shared memory took out a POSIX shared file lock, then it could be detected whether a shared memory object were still in use and if not, removed.
In case it isn't obvious, if the process exits unexpectedly, the shared file lock is dropped, and thus this technique handles sudden process exit.
Interesting idea Niall, thanks. Ion