I used boost's named_semaphore for IPC. We have one program/process (parent) invoking another (child). If the parent is killed (kill -9 scenario), we want the child to complete its work and exit, and the parent shall, upon starting wait until the child signals (by means of boost::named_semaphore).
This all works quite well, except that the other day on windows I got quite a surprise when I cleared the event log (it happens...) to find out the boost (to obtain kernel persistence shared memory) uses shared memory, and the folder which they use for this uses for its name a timestamp that it obtains (by default) from the event log (in the case of windows only).
Granted, I have not read their IPC documentation entirely (perhaps I believe to firmly in encapsulation...), and I especially did not realize named_semaphore's dependency on shared_memory... (encapsulation).
This / the default behavior of using the Startup Time in the event log from here is too fragile for my liking. They do give some options, but I'm not sure which is the most robust, whilst requiring the least amount of work from my part. Specifically, what degree of robustness has defining BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME and why is this not the default?
I'm assuming that if I use a strategy, both parent and child processes must use exactly the same strategy, otherwise the named_sema won't work?
Any thoughts would be welcome.