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.
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.
> 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.
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
-- 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk