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