Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-16 20:06:02

----- Original Message -----
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**, 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?

-Dave

**I can't speak for others, but in general your posts tend toward supplying
material that I don't know what to do with. Large stretches of POSIX
standard and pthreads-specific code or multiple links to message threads are
difficult to deal with, especially when they come with no interpretive
material. These are domains in which you have expertise and relative
comfort; it would help a lot if you could try to summarize your conclusions,
highlight what you think is important, and generally guide the reader when
you post references... for those of us less-familiar with the material.