[c++-pthreads] Restating the Jason model

[Wil Evers]

Jason Merrill wrote:

> On Tue, 13 Jan 2004 21:19:15 +0100, Wil Evers <wil at bogo.xs4all.nl> wrote:
 >
>>It is true that an exception escaping from a destructor will not trigger
>>immediate program termination when the program/thread in question is not
>>unwinding; however, that doesn't mean there's nothing to worry about. The
>>most likely symptom is a resource leak; in a multi-threaded environment,
>>that could mean a deadlock.
>  
> True, throwing out of a destructor is more likely to cause trouble than
> throwing from other places; a destructor like
> 
>   Guard::~Guard()
>   {
>     write (0, "releasing", sizeof ("releasing");
>     release (resource);
>   }
> 
> will fail to actually release the resource if a cancel is delivered during
> the call to write().  It's certainly possible to restructure code to avoid
> this problem, but I can see this being a source of hard-to-debug problems.

The situation is actually a bit more complicated: many container 
implementations, including the ones in the C++ standard library, assume 
that the destructors of their elements do not throw.   Most likely, an 
exception escaping from one element's destructor will cause the 
remaining elements to be abandoned (and not destroyed at all).

> This is a somewhat persuasive case for disabling cancel during all
> destructors, but I'm not sure it outweighs the overhead involved.  In the
> model I proposed, only the EH runtime needs to know about cancellation.

As I tried to say before, my main objection to your model is that, 
depending on the thread's dynamic context, destructors will behave 
differently when hitting a cancellation point.  Sometimes, your model 
will protect us from cancellation exceptions, but at other times it 
won't, and I fear the confusion that might result from this.

I agree that the overhead of disabling cancellation in all destructors 
could become a problem.  IMO, if we have sticky cancellation, the EH 
runtime doesn't need to be disable cancellation either.

Most destructors only deal with releasing memory anyway, and don't need 
to call any throwing functions.  Some destructors do more complicated 
things, involving calls to functions that *do* throw exceptions.  These 
destructors must take extra precautions and are harder to implement, but 
this has always been the case - ever since exceptions were added to C++.

The thing that changes because of cancellation is that some functions 
that didn't throw before will now be licensed to do so.  It seems to me 
that most of the participants on this mailing list accept that this will 
require changes to existing code.  That could include adding a try/catch 
block to destructor code.

- Wil