Re: [Boost-users] [IPC Named Mutex]

Subject: Re: [Boost-users] [IPC Named Mutex]
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2015-05-28 14:50:48

El 28/05/2015 a las 12:13, Niall Douglas escribió:
> On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
>
>>> Given that the failure was somewhere related to directory names, what's
>>> probably happening is that it's trying to find the name of its shared
>>> directory.  For that it evidently wants to use the boot time, as it's a
>>> value that should be identical for all processes started since the last
>>> reboot, but different between reboots (to avoid getting stale data).
>>
>> Yes, that's the idea. Obtaining this "unique" identifier between reboots
>> that remains stable between all processes it's been incredibly
>> difficult. Any alternative or suggestion is welcome.
>
> On Windows you can mark a filing system entry as always deleted on
> close. Such an entry will be deleted on close no matter what,
> including power loss and filesystem corruption (the chkdsk with
> delete such still existing items).
>
> If you therefore need a synchronisation object to exist only for this
> boot cycle and to always disappear in the next boot cycle, delete on
> close is an excellent way of doing it. Why the Windows Temp files
> don't default to delete on close is beyond me (you can also unset
> delete on close at any time on an open file handle).

Can you elaborate, please? What's a "filling system entry"?

Delete-on-close would delete the resource when the last attached process 
exits, so it would be deleted before system reboot a new processes could 
not connect to the resource. Or am I missing something?

Thanks

Ion