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/interprocess/detail/portable_intermodule_singleton.hpp#L124-L128 > https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/detail/portable_intermodule_singleton.hpp#L47-L71 > > 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. Niall _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
