
On 8/28/2011 9:08 AM, Ion GaztaƱaga wrote:
I'm integrating a patch kindly sent by Ross MacGregor that activates a timeout when locking, if a define is set. When you can't lock a mutex for a time longer than X milliseconds, a special exception is thrown. Then you should erase that resource (message queue or whatever) as it is likely to be corrupted by the crashing process.
I hope we can put this in Boost 1.48.
That would be great.
I repeat, you still have lifetime issues so we can't maintain message queue lifetime semantics and use simple CreateMutex.
I agree with you. It's finally sinking in that the mechanism I'm really looking for is a message queue but with process lifetime....and it would be fine for me to use windows_shared_memory only if that's easier. It does seem easier to use since there's less of a distinction between the two processes using the queue -- both can open_or_create and neither one needs to remove. And, I don't need to build anything in my protocol do deal with stale messages leftover from previous processes. If anyone has code for something like this, I'd love to see it. Even assuming an interprocess_mutex implemented with CreateMutex, I'm not sure what the corresponding changes need to be in interprocess_condition. Or that this is even the right way to go in the first place. Thanks much. -DB