> > but if it is too inefficient, we could:
> >
> > 1. go with Peter's proposal of an additional version of mutex_lock
> > that is not a cancellation point, or
> >
> > 2. we could say that if people want their mutex_lock to be a
> > cancellation point, they can call_check_for_cancellation manually before
> > locking, or write a wrapper.
> >
> > Which is the right answer?
>
> The right answer is awaiting you here:
>
> http://groups.yahoo.com/group/boost/message/22881
>
> one more hint: it will throw AND "protect" but it won't be
> a "mutex", in the sense of "pthread_mutex_t" class objects.

<flame>
I didn't the quote from PTHREADS docs saying that "it has not yet been shown" to be very useful. I also don't really find "The right answer is awaiting you" very useful. Reading this news group should not be an easter egg hunt, an introduction along the lines of "I like the PTHREADS solution of this, see this thread for a full description:".

I apologize if I'm being harsh, but the topic is already difficult enough to understand and follow as it is.
</flame>

If the intent is to enable explicit cancellation points I don't see much difference between options 1 and 2. Wouldn't option 1, if needed, probably be implemented in terms of the second?