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/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?

I consulted with Peter Dimov and he pointed out this link to me:

https://stackoverflow.com/questions/78451323/initialization-of-boostflyweightsintermodule-holder-fails-with-interprocess

Also, may it be related with this lame implementation of get_current_process_creation_time?

https://github.com/boostorg/interprocess/blob/a847fcf0ecab3d26e4aa3b9a0d7adab12fd5a00a/include/boost/interprocess/detail/os_thread_functions.hpp#L479-L480

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/boost_macro_reference.html#boost_config.boost_macro_reference.macros_for_libraries_with_separate_source_code.macros_controlling_shared_library_symbol_visibility

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