Re: boost::flyweights::intermodule_holder

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2024-05-09 17:48:34

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