Boost logo

Boost :

From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-01-17 12:14:58

> > 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:
> one more hint: it will throw AND "protect" but it won't be
> a "mutex", in the sense of "pthread_mutex_t" class objects.

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.

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?

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