Re: first sight

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

Me too.

> 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**, 

Just go back to:

http://groups.yahoo.com/group/boost/message/22836

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

http://groups.yahoo.com/group/boost/message/22881

one more hint: it will throw AND "protect" but it won't be 
a "mutex", in the sense of "pthread_mutex_t" class objects.

regards,
alexander.