Re: [c++-pthreads] Restating the Jason model

[Jason Merrill <jason@xxxxxxxxxx>]

On Tue, 13 Jan 2004 07:47:17 -0500, Dave Butenhof <David.Butenhof@xxxxxx> wrote:

> Jason Merrill wrote:

>> * Which bits of the C++ library are cancellation points?
>>
>>I would think pretty much all I/O code, and nothing else.
>>
> Not just "I/O", but in general any explicit control point that might
> "indefinitely block".

Agreed, but I don't think there is anything else in the C++ standard
library that fits that description.

>>Closely related to this is the question of what happens if a cancellation
>>exception is thrown under a formatted I/O function; currently it would be
>>caught and discarded, so it would only escape on a flush or the like.  I
>>think it should escape from formatted I/O as well.

> Idealism suggests supporting the application developers' desire for
> consistency and predictability. Pragmatism argues against forcing all C++
> runtimes to be substantially analyzed and modified. Pragmatism won in POSIX
> as it usually did, and many of the arguments I've seen in this group
> suggest (unscientifically) that C++ committee members might share some
> similar biases.

I think the impact on runtime developers of this change would be minimal;
it's a pretty mechanical change since the functions in question already
have to deal with exceptions thrown out of their subroutines.  It seems to
me that the only question is whether or not we *want* the cancel to
propagate out of these functions.  Presumably the designers of iostreams
had a reason for blocking all exceptions in the formatted i/o functions;
I'm not familiar with this rationale, so it's hard for me to judge whether
or not it applies to cancel as well.

>> * Should cancellation also be disabled in destructors run during normal
>>   execution?  In catch blocks?
>>
>>IMO, no and no.
>>
> Cancellation should NOT be disabled in destructors? Did you mean to say
> that?

Yes.  Destructors can be run under two different situations: 

 1) when the object goes out of scope during normal execution; 
 2) when unwinding the stack during exception handling.

In #1, an exception thrown out of a destructor is propagated normally.  In
the #2, it causes a call to terminate().  So we need to suppress
cancellation for #2, but not (necessarily) #1.

>> * 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.

> Additional operations on the cancel object. Interesting. Like, for example,
> if the cancel object destructor were to automatically re-pend the cancel
> unless the handler had already declared "cancel.finalize()"?

Yes, that's the main one I was thinking of.

> (Could or should this be done automatically be the runtime for
> 'catch(cancel)' as opposed to 'catch(...)'?)

It could, but that strikes me as excessively clever.  :)

>> * What about pthread_exit?
>>
>>I'm happy with the g++ status quo whereby destroying a pthread_exit
>>exception calls terminate.  Unlike cancellation, the position of a call to
>>pthread_exit is deterministic, so the user is responsible for making sure
>>that it can propagate.
>>
> Well, yes; although it also seems better to make one new rule for the new
> "thread terminating exceptions" rather than two separate new rules.

There's no way to use the same rules for both, since we can't re-assert
deferred exit.

Jason