Re: [c++-pthreads] The Ada example

[Jason Merrill <jason@xxxxxxxxxx>]

On Fri, 19 Dec 2003 07:45:02 -0500, Ted Baker <baker@xxxxxxxxxx> wrote:

> First, you are stuck with the POSIX thread implmentations.
> They do not provide any way of catching thread cancellation.
> All they do is guarantee that somehow the cleanup routines
> will be executed and then the thread will terminate.
>
> Furthermore, the POSIX/UNIX standards do not define the
> semantics for continuation of a thread after cancellation.

Right, but we can define those semantics.  This discussion assumes control
over the thread implementation.

> Back when the POSIX threads standard was being balloted, one of
> the things the Ada folks asked for was that is should be possible
> to do a longjmp() from a cancellation cleanup routine, and that
> longjmp() would execute the stack of cleanup handlers out to the
> point of the corresponding setjmp().  The balloting group was
> immovable on this.

That's what we in the ia64 C++ ABI group called longjmp_unwind.

I note that the POSIX spec explicitly leaves the semantics of longjmp out
of a cancellation cleanup undefined, so an implementation is free to give
it the semantics you suggest.

But what would you expect the effect of such a longjmp to be on the
cancellation request?  And what happens if one of the cleanups run by this
longjmp also calls longjmp?

More generally, how does Ada deal with this situation?  From looking over

  http://www.adaic.org/standards/95lrm/html/RM-9-8.html

it seems that task abort runs finalizers for objects, but doesn't interact
with exception handling.  In C++, the only way to run object destructors is
via exception handling, unless we want to define a whole new parallel
concept, which I doubt.

>>> * What happens if the exception is caught, and not rethrown?
>> Nothing special. Pls see "example" in the message referenced below.
>
> This violates basic principles of abstraction and information
> hiding.
>
> 1) The expected effect of cancellation is to terminate a thread.
> Anything that does not result in termination of the thread breaks
> the abstraction.

Yes.

> 2) If you allow local handling of cancellation, without
> rethrowing, a hidden operation, many levels deep, may nullify the
> intended effect of cancelation.  This becomes a serious
> maintenance problem, as some newbie programmer decides to protect
> his favorite critical section against cancelation and forgets to
> rethrow it.  Suddenly, you have an intermittent bug that will be
> *very* hard to track down.  How often will a thread be cancelled,
> and how often will it be cancelled at that point? Imagine trying
> to reproduce this kind of failure.

It's worse than that--the programmer just has to decide that his code
shouldn't throw any exceptions, and wrap it with a catch-all handler.  This
happens in some of the C++ I/O code, which if left unchanged would mean
that a thread which does a lot of I/O may cancel when you ask it to, or it
may decide to discard the request.  And a long sequence of I/O seems to me
like something that we might often want to cancel.

There's no way for the thread which sends the cancellation request to
determine that the cancellation has beens swallowed, and it needs to send
another.  I suppose this is the sort of thing that leads to users madly
clicking on cancel buttons until the program finally responds.

Jason