boost::flyweights::intermodule_holder
Dear All, Thanks for the boost library! Apparently the boost::flyweight::intermodule_holder on LINUX is creating shared memory objects, which by accident (crash?) can persist after the process having created them is already gone. As a result I ran into the following situation: I could not successfully run some code, as it attempted to create an already existing shared memory object created by another user. Would the following be a solution to this problem: Use a copy of the code of the static_holder inside another namespace as attached and compile one module with __INCLUDE_HOLDER__ defined and all the rest without this define? Peter
BTW - I gave up trying to use explicit template instantiation inside a .cpp file. From: Foelsche, Peter (DI SW ICS CICV R&D SIM1 5) Sent: Thursday, May 9, 2024 9:42 AM To: boost-users@lists.boost.org Subject: boost::flyweights::intermodule_holder Dear All, Thanks for the boost library! Apparently the boost::flyweight::intermodule_holder on LINUX is creating shared memory objects, which by accident (crash?) can persist after the process having created them is already gone. As a result I ran into the following situation: I could not successfully run some code, as it attempted to create an already existing shared memory object created by another user. Would the following be a solution to this problem: Use a copy of the code of the static_holder inside another namespace as attached and compile one module with __INCLUDE_HOLDER__ defined and all the rest without this define? Peter
El 09/05/2024 a las 16:41, Foelsche, Peter via Boost-users escribió:
Dear All,
Thanks for the boost library!
You're welcome!
Apparently the boost::flyweight::intermodule_holder on LINUX is creating shared memory objects, which by accident (crash?) can persist after the process having created them is already gone.
As a result I ran into the following situation:
I could not successfully run some code, as it attempted to create an already existing shared memory object created by another user.
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? I consulted with Peter Dimov and he pointed out this link to me: https://stackoverflow.com/questions/78451323/initialization-of-boostflyweigh... Also, may it be related with this lame implementation of get_current_process_creation_time? https://github.com/boostorg/interprocess/blob/a847fcf0ecab3d26e4aa3b9a0d7ada... In any case, we need Ion here.
Would the following be a solution to this problem:
Use a copy of the code of the static_holder inside another namespace as attached and compile one module with __INCLUDE_HOLDER__ defined and all the rest without this define?
I __think__ this would work, yes. Remember to define get with the proper visibility attributes: https://www.boost.org/doc/libs/develop/libs/config/doc/html/boost_config/boo... Please let me know if this works for you --it may be a worthy addition to Boost.Flyweight. Joaquín M López Muñoz
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. Niall
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
participants (4)
-
Foelsche, Peter -
Ion Gaztañaga -
Joaquin M López Muñoz -
Niall Douglas