On 8/19/2011 11:21 PM, Ion Gaztañaga wrote:
El 20/08/2011 1:57, David Byron escribió:
Except that the above code is in message_queue.hpp even in try_send or timed_send. It's in get_num_msg() for example. So short of modifying message_queue.hpp I'm not sure what to do.
Sorry, I didn't understand you. In those cases, the only solution would be to configure at compile time (macro or whatever) a maximum lock time and throw an exception just to notify that a deadlock might be ocurring. Detecting the dead of a mutex owner is not an easy task without kernel support.
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. At the moment I see two implementations in interprocess/sync/interprocess_mutex.hpp -- a posix one and emulation/mutex.xpp. My understanding is that a process waiting on a posix interprocess_mutex wakes up (having taken ownership) if the owner process dies. Is that right? Adding an implementation for windows that behaves that way feels like a big bonus -- way better than hanging. Is something like this feasible? I'm fairly new to boost so I have a feeling creating a patch is going to be pretty slow going but but I'll take a crack if it would help. Barring this, I'm struggling to come up with a safe way to use boost::interprocess::message_queue on windows (or any platform that uses the emulation interprocess_mutex really). If anyone has any suggestions, I'd love to hear them.
One thing that came to mind is always calling message_queue::remove on startup. I think that gets passed this problem, but may introduce some other complications if the two processes that use the message queue start and end at undefined times in an undefined order. I'm still trying to test this, but perhaps you can help by answering this question:
If a process is waiting for the mutex like this:
scoped_lock
lock(p_hdr->m_mutex); what happens if another process removes the message queue?
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? Thanks for your help. -DB