Re: [boost] Boost.Threads, N2178, N2184, et al

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-03-27 08:27:46

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> David Abrahams wrote:
>> I suggest that trying to use meanings of "cancellation" other than the
>> one(s) used in the pthread standard at this point can only confuse
>> things, which hardly seems like a way to un-stall the process.
>
> I might be completely wrong, but doesn't the pthread standard
> require a thread to stop once it has been cancelled?
> The thread may decide to defer the request, but not to deny.
> Correct?

Well, it may defer the request forever by never enabling cancellation, or the
code may register a cleanup handler that essentially restarts processing.

> So what we are discussing (and what I want to suggest too) is
> to let the thread decide if it honours the cancellation request.

Yes.

> My point was just to give it a different name then, since this
> basically is a communication channel that can be used for
> other purposes too.

Fair enough. If you make it generic (e.g. t.raise(some_exception)), then you
have to write code to deal with arbitrary exceptions being thrown from what
essentially amounts to arbitrary points.

t.raise(std::bad_alloc());

namespace{
struct type_with_unknown_name{};
}

t.raise(type_with_unknown_name());

Aside from the exception-transportation problems, I'm not keen on this.

t.request_cancel() says what we really mean, and t.cancel() strikes me as
acceptable shorthand.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL