Re: [boost] [interprocess] More robust message_queue and interprocess_condition?

Subject: Re: [boost] [interprocess] More robust message_queue and interprocess_condition?
From: kopo (kopinskc_at_[hidden])
Date: 2011-05-05 08:55:44

Sent from my iPhone

On May 5, 2011, at 6:45 AM, "kopo [via Boost]" <ml-node+3498130-1173126325-232438_at_[hidden]> wrote:

> Ross MacGregor wrote:
> Not that I am aware, I think many assumed it was too difficult to fix. 
> But I have a proposed solution to which I am trying to generate some 
> feedback. I am using the "Solution 1" modification to the library myself. 
> For me, introducing a message_queue timeout was a far better than having 
> the interprocess library deadlock. 
> I meant to reply to your original message with proposed solutions but clicked on the wrong post. I definitely thought that your first solution was probably the best, and plan on using it if no other solutions can be found. 
> 
> Ross MacGregor wrote:
> Are you using message_queue or interprocess_condition? I don't know 
> what you mean by "non-invasive". The only solutions outside of a 
> library fix are: 
>  1) Monitor your thread for a deadlock and kill it if it is and cleanup. 
>  2) Ensure your processes are never terminated. 
> 
> I think #2 is how the library is meant to be used, but IMHO this is not 
> a requirement most real world applications can satisfy.
> I was planning on using message_queue to pass log messages between external processes and a central logger. 
> 
> 1) This really could happen on any thread, so monitoring each thread for deadlock is not an option, let alone terminating it. 
> 2) I would love to ensure that my logger process never terminates, but we don't live in a perfect world and if it terminates abnormally (or even normally) I need the other processes to function normally. 
> 
> When I say non-invasive solution it would be best not to modify the library so that other people that wish to use my API could do so with the existing BOOST code base and not have to take out a specially modified version. I also want my consumers to have the ability to upgrade if bug fixes come out for the library. 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://boost.2283326.n4.nabble.com/interprocess-message-queue-hangs-when-another-process-dies-tp2648488p3498130.html
> To unsubscribe from [interprocess] message_queue hangs when another process dies, click here.

--
View this message in context: http://boost.2283326.n4.nabble.com/interprocess-message-queue-hangs-when-another-process-dies-tp2648488p3498278.html
Sent from the Boost - Dev mailing list archive at Nabble.com.