Re: boost::flyweights::intermodule_holder

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-09 17:56:11

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.

Niall