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

Subject: Re: [Boost-users] [IPC Named Mutex]
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-05-29 13:09:18

On Thu, May 28, 2015 at 3:41 PM, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> El 28/05/2015 a las 21:02, Michael escribió:
>>
>> On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" <igaztanaga_at_[hidden]>
>> wrote:
>>>
>>> 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?
>>
>>
>> Wouldn't it be a moot point when all mutex consumers closed? Next one
>> fires up and requests a brand new round of shared mutex.
>
>
> That could work with a mutex, half-work with a semaphore (the count should
> remain stable after the last process closes the handle) and broken for a
> shared memory object.
>
> The key is how to find a unique identifier that identifies each reboot. I've
> tried:

I'm not positive, but you would need to predetermine something about
it. A resource, location, or what have you. Either a file, whether
counting or not (i.e. sem.). Existing of that file, maybe uuid-named
for uniqueness between sessions, single file (if content in
directory), or something along these lines.

As long as that protocol was adhered to, should be no problem?

> -> kernel boot time. It changes when clock is adjusted
> -> WMI LastBootUpTime. A lot of problems with my poor implementation and
> problems after hibernation and clock changes.
> -> Look for event ID == 6005 (event log started) in the System event log:
> problems when too many events are appended to the log as that event is lost.
>
> Any ideas?
>
> Best,
>
>
> Ion
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users