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

Subject: Re: [Boost-users] [IPC Named Mutex]
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-05-27 19:25:26

On 28/05/2015 04:00, Ion Gaztañaga wrote:
> El 26/05/2015 a las 8:08, Gavin Lambert escribió:
>> 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.

Use CreateFileMapping to create a named (simple constant name) mapping 
*not* backed by a file.  Store whatever data you want in here; this can 
include a randomly-generated value used to look up other items if you 
wish (generated by the first process to create the mapping and then used 
by all subsequent processes -- you may need to use a mutex either within 
the mapping or via CreateMutex to resolve races if multiple processes 
simultaneously access the mapping for the first time).

The mapping data will automatically exist only until the next reboot or 
until the last application using it closes it.  (It will also by default 
exist only for the current user session, which is usually what you 
want.)  For IPC between concurrently running processes, this is usually 
sufficient -- the only case it can't handle is if you want to support 
running process A which leaves some "shared" object in a particular 
state but then exits before process B starts and expects to be able to 
read that state.  But that would be a very weird design.

Unless there's some really compelling reason not to, you should really 
store all the IPC data in the kernel namespace rather than the 
filesystem.  Filesystems are slow.