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

[Jason Merrill <jason@xxxxxxxxxx>]

On Tue, 13 Jan 2004 21:19:15 +0100, Wil Evers <wil@xxxxxxxxxxxxxx> wrote:

> Jason Merrill wrote:
>
>> On Tue, 13 Jan 2004 07:47:17 -0500, Dave Butenhof <David.Butenhof@xxxxxx> wrote:
>  >
>>>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.
>
> 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.

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.

Jason