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

29 May 2015


      On Thu, May 28, 2015 at 3:41 PM, Ion Gaztañaga  wrote:
...
El 28/05/2015 a las 21:02, Michael escribió:
...
On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" 
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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

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

Michael Powell