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.
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, Ion