Actions

icon Post
text/html Subscribe
text/html Unsubscribe
CodeSourcery > List Archives
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost

  • To: David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>
  • Subject: Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost
  • From: Jason Merrill <jason@xxxxxxxxxx>
  • Date: Tue, 14 Mar 2006 16:37:45 -0500
David Abrahams wrote:

"Meredith, Alisdair" <Alisdair.Meredith@xxxxxxxxxxxxxxxx> writes:

In the model I'm proposing, cancellation will be expressed by telling
the cancelled thread to throw a specific exception object at the next
(or current) cancellation point reached with cancellation enabled.
All exceptions are catchable.  Exceptions can be unstoppable, if you
write them in a particular way.


Hmm....

extern "C" int printf (const char *, ...);

struct E
{
  bool undead;
  E(): undead (true) { }
  ~E() { if (undead) throw E(); }
};

int main()
{
  try
    {
      try
        {
          throw E();
        }
      catch (...)
        {
          printf ("caught once\n");
        }
    }
  catch (E& e)
    {
      printf ("caught twice\n");
      e.undead = false;
    }
}
This works in g++, but EDG calls terminate() when the destructor throws. I think g++ is correct; 15.5.1 doesn't mention throwing during destruction of the exception object due to flowing off the end of the handler as one of the situations that causes terminate() to be called, and I don't see any reason why it would need to be.
We would still call terminate() if the catch(...) block exits by throwing another exception, since then the exception object is destroyed during stack unwinding. 


ii/ if cancellation passes through an exception specification, we
call unexpected and abort which pretty much achieves the same thing


No, it doesn't complete stack unwinding, and it might kill the whole
process (I'm not sure about that).


iii/ if cancellation interupts a dtor during regular stack
unwinding, we call terminate which pretty much has the same effect,
so everyone is still happy. 

Likewise.
In previous discussions everyone has agreed that cancellation should be disabled during stack unwinding, to avoid this situation. This could be implemented either by the EH runtime calling pthread_setcancelstate or by the cancellation runtime checking to see if it's safe to throw a la Alexander. 

Jason