2011/10/30 Ion Gaztañaga <igaztanaga@gmail.com>:
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