[c++-pthreads] Restating the Jason model
Alexander Terekhov
boo at terekhov.de
Tue Jan 13 11:58:42 UTC 2004
Jason Merrill wrote:
>
> I think this is an appropriate time to restate my proposal. I think
> there's a fair amount of consensus around these three points:
>
> * Cancellation is a normal exception.
Agreed.
> * If a cancellation exception is destroyed, the cancellation request
> is re-entered, and acted on again at the next cancellation point.
Disagreed.
> * Cancellation is disabled during unwinding.
Only when propagating thread termination request exception (base class
for both thread_cancel_request and thread_exit_value<>). See also POSIX
TC2 (Change Number: XSH/TC2/D6/7 [XSH ERN 77]).
>
> But there are still some open questions:
>
> * Which of the POSIX cancellation points are cancellation points in C++?
All.
[...]
> * Which bits of the C++ library are cancellation points?
>
> I would think pretty much all I/O code, and nothing else.
I would think C++ library should have a lot of async-cancel-safe stuff.
[...]
> * Should cancellation also be disabled in destructors run during normal
> execution?
Not by the implementation (2-phase EH aside for a moment).
> In catch blocks?
That depends.
>
> IMO, no and no.
See POSIX TC2 (Change Number: XSH/TC2/D6/7 [XSH ERN 77]).
>
> * How can C++ code interact with a cancellation exception?
>
> I think everyone agrees that it should be possible to catch a cancel by
> name. We still need to specify that name and any additional operations the
> cancel object might support.
Yes.
>
> * What about pthread_exit?
http://www.codesourcery.com/archives/c++-pthreads/msg00005.html
>
> I'm happy with the g++ status quo whereby destroying a pthread_exit
> exception calls terminate.
I'm not happy with that. Why should the g++ care what I do with *MY*
exceptions?
regards,
alexander.
More information about the c++-pthreads
mailing list