Re: boost::flyweights::intermodule_holder

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2024-05-10 10:18:30

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