Re: [boost] [interprocess] native Windows cond_var + mutex

Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2011-10-31 04:29:53

2011/10/30 Ion Gaztañaga <igaztanaga_at_[hidden]>:
> El 30/10/2011 21:23, Dan Brown escribió:
>> [...].  There can be logical
>> persistence for some objects via their name even if there isn't
>> physical persistence.
>
> No, I can create shared memory write anything into it and unmap it. In
> windows it would be destroyed. In UNIX another process could read anything
> the first process has written.

I've worked on an app where this was worked-around by a little spawned
"tray" app that referenced the "persistent" shared-memory segments,
and this was achieved using Windows-specific COM interfaces (since
this is a Windows-specific work-around, that sounds reasonable). Once
registered, the little tray app would be re-spawned automatically if
1) the user logged out, or b) the machine rebooted (Windows update
anyone...), and c) the user explicitly exited the tray app. It's not
of course file-like in its persistence, but quite adequate and often
sufficient. I'm sure you're aware of this type of work-around, so I
guess my question is why this is not included out-of-the-box in
Boost.Interprocess?

One can also easily imagine service (i.e. daemon) based work-arounds,
but these are the disadvantage to require more permissions to install
I guess, with the benefit to survive a logoff. (I usually have Local
Admin rights, so maybe just the COM registration requires some rights
to write the registry...)

I think I also remember on this list discussions about
Windows-Kernel-based ways to keep the SHM segments around.

These are all work-around, but having any one of those in
Boost.Interprocess would be "nice"! :)

Thanks, --DD