Boost logo

Boost :

Subject: Re: [boost] [interprocess] More robust message_queue and interprocess_condition?
From: kopo (kopinskc_at_[hidden])
Date: 2011-05-05 07:45:23

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.

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at