From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-17 12:38:47
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "David Abrahams" <david.abrahams_at_r...>
> > From: "terekhov" <terekhov_at_d...>
> > > > I'm still trying to determine what should be a cancellation
> > > and
> > > > what shouldn't. That's why I'd really appreciate your
> > > the
> > > > pros/cons of having the mutex lock be a cancellation point.
> > > > fairly certain it shouldn't be, but at the very least I'll
> > > > document the rationale behind that decision.
> > >
> > > Just ask Peter whether he wants that his shared_ptr's
> > > ++ and -- would start throwing exceptions by default
> > > in thread-safe version of his class.
> > Was Peter going to implement pointer arithmetic? I don't think
> > mean when the reference-count is incremented/decremented? If so,
> > that it would be a nearly disastrous design. That's why we can
> > cancellation, right? In response to my query about how efficient
> > to disable cancellation you posted a big wad of code that I'm not
> > to interpret**,
> The point was that the cancellability property of a thread is not a
> local, therefore has to be protected by a mutex; so setcancelstate
() has a
> mutex lock inside it.
I'm not sure that was the point. If it was, I don't know that it
holds any meaning. This implementation detail need not use the same
mutex type, nor the same locking mechanism, so need not be a
cancellation point and thus won't throw. This does
mean "significant" performance overhead when enabling/disabling the
BTW, is it really true the cancellability is not thread local? Can
other threads actually change the cancellability of a thread? You
can't in POSIX and I don't see why you would here either. The cancel
request flag must be shared and protected, yes, but that's different
> > 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
> > point, they can call_check_for_cancellation manually before
> > write a wrapper.
> > Which is the right answer?
> (2) is. I'm now nearly convinced that the pthreads way is the
> and any deviation will prove to be a mistake. IOW I think that the
> C++ threading library should follow pthreads - in every aspect.
Not in every respect, though there should be fewer differences then
there is now. I'm working on that.
In any event, I'm fairly convinced of (2) as well, but I've yet to
see rationale that will hold up. (Or at least I've not understood
something if the provided rationale holds up.)
> It's clear from Butenhof's posts in c.p.t that pthreads have been
> specified to interact well with C++ implementations; for example,
> cancellation is based on an existing implementation that used C++
> exceptions, it's intended to play well with C++ exception handling
> (cancellation requests invoke destructors, C++ exceptions invoke
> cleanup handlers), and pthread_clenup_push/pop are intended to be
> (implementable as)
Intended, but not gauranteed, unfortunately. In any event, a post
from him copied on this list shows that there are still some
considerations that should be made in C++ that go beyond that
specified by POSIX. And those considerations are exactly what we've
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk