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/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.
Interesting idea Niall, thanks.
Ion
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
