Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-17 08:09:33


----- Original Message -----
From: "terekhov" <terekhov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 17, 2002 3:56 AM
Subject: [boost] Re: first sight

> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> >
> > ----- Original Message -----
> > From: "terekhov" <terekhov_at_d...>
> >
> > > Just go back to:
> > >
> > > http://groups.yahoo.com/group/boost/message/22836
> > >
> > > and this time just do a search on "mutex".
> >
> > Yes, it locks a mutex in order to implement cancellation
> protection. Why
> > isn't it just accessing TLS at this point?
>
> "/*
> * Lock for async-cancel safety.
> */" ^^^^^^^^^^^^^^^^^^^
>
> to prevent "double-" cancel. fyi.. you might
> also want to have a look at the attached message
> (with respect to the pthread-win32 code posted).

What's a "double-" cancel?

I read all of the messages at the other end of links you've posted, but I
don't understand what you're trying to say yet.

> > It seems strange that other
> > threads should be contending for this thread's notion of whether
> > cancellation is disabled.

It still does, to me.

> > > 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.
> >
> > This one just looks like another of your mysterious links to me. I
> can't
> > understand what I read there, and the comment above is a bit
> too "hint-y"
> > for me to understand.
>
> pthread_mutex_timedlock() Rationale:

<snip>

Sorry, I read it, but what do the properties of timedlock() have to do with
cancellation?

> Perhaps you just contact Butenhof if you still
> have any more "why" question wrt mutex locking
> and cancelation.

We're definitely not at that stage yet. I'm just trying to figure out what
/you're/ driving at.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk