Roland Schwarz <roland.schwarz@chello.at> 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