On 8/25/2011 9:56 PM, Ion Gaztañaga wrote:
El 25/08/2011 20:53, David Byron escribió:
Instead of using a persistent integer on windows, how about CreateMutex Then if the mutex holder dies, the other side learns about it because WaitForSingleObject returns WAIT_ABANDONED. But then it's not so important to learn that the other side is dead...just that we've got the mutex and it's OK to proceed.
The key problem is object lifetime. In windows, when last attached process dies/closes the handle, the interprocess mechanism is automatically destroyed. In Unix, it's more like a file and an explicit unlink must be done. That's the real problem of portable semantics between windows and unix.
I see. So I guess I repeat my earlier comment/question (slightly modified): I'm struggling to come up with a safe way to use boost::interprocess::message_queue. If anyone has any suggestions, I'd love to hear them.
The queue is removed (in windows, the name of the queue is changed so that no other connection succeeds and marked to be erased when the last handle is closed,
That's useful information, but what I'm also curious about is whether the process waiting for the mutex wakes up or not. Using the emulated interprocess_mutex, I'm not sure. Because the waiting process still likely has a handle, I guess it hangs forever, yes?
It will hang, yes, just like in a posix system without robust mutex support. Adding robust mutex support is in my to-do list, exploring some emulation for windows too, but I guess that would require a huge amount, because I don't know any portable runtime that has achieved this.
If CreateMutex behaves the "right way" on windows, does it make sense to have the behavior differ across platforms? Do you agree that using CreateMutex instead of the emulation mutex would prevent hangs? Are there other downsides I haven't considered? -DB