Re: [boost] Re: first sight

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-17 07:03:30

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "terekhov" <terekhov_at_[hidden]>
>
> > > I'm still trying to determine what should be a cancellation point
> > and
> > > what shouldn't.  That's why I'd really appreciate your writing up
> > the
> > > pros/cons of having the mutex lock be a cancellation point.  I'm
> > > fairly certain it shouldn't be, but at the very least I'll have to
> > > 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 so. Maybe
you
> mean when the reference-count is incremented/decremented? If so, I agree
> that it would be a nearly disastrous design. That's why we can disable
> cancellation, right? In response to my query about how efficient it might
be
> to disable cancellation you posted a big wad of code that I'm not
qualified
> to interpret**,

The point was that the cancellability property of a thread is not a thread
local, therefore has to be protected by a mutex; so setcancelstate() has a
mutex lock inside it.

> 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?

(2) is. I'm now nearly convinced that the pthreads way is the correct way,
and any deviation will prove to be a mistake. IOW I think that the standard
C++ threading library should follow pthreads - in every aspect.

It's clear from Butenhof's posts in c.p.t that pthreads have been carefully
specified to interact well with C++ implementations; for example, pthreads
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 pthreads
cleanup handlers), and pthread_clenup_push/pop are intended to be
(implementable as)

#define pthread_cleanup_push   do { __cleanup_handler __temp
#define pthread_cleanup_pop    } while(0)

--
Peter Dimov
Multi Media Ltd.