Boost logo

Boost :

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-17 02:33:52

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> 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 writing
> > 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
> > > 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.

Me too.

> Maybe you
> mean when the reference-count is incremented/decremented? If so, I
> that it would be a nearly disastrous design. That's why we can
> 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
> to interpret**,

Just go back to:

and this time just do a search on "mutex".

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


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