Help: Unwinding the C++ stack...throw, longjmp & threads

[Jason Merrill]

>>>>> Josh Stern <jstern@citilink.com> writes:

 > Joe writes:
 >> Josh writes:
 >>> If this extension would allow exceptions to be thrown from
 >>> Unix signal handlers, that would be a very cool feature
 >>> for even non-threaded programs.

 >> It wouldn't, since we don't support that in C++ either.  The problem
 >> is that signals can happen anywhere.  Consider
 >> 
 >>   char * buf = 0;
 >>   try {
 >>        buf = malloc(buf_size);
 >>   }
 >>   catch (SIGNAL) {
 >>        if (buf)
 >>                free(buf);
 >>   }
 >> 
 >> This code has a race and a leak, and there's no way to write it correctly,
 >> because the signal could come after malloc has allocated memory but before
 >> buf is assigned.

 > I understand the example, and also (I think) Jason's comment that 
 > asynchronous exceptions are very hard to  get right.  Just to
 > pursue this a little bit however...

 > I would diagnose the problem above as an inadequate implementation
 > of malloc() (relative to use in a program that could throw from
 > a signal handler).  An acceptable malloc for such a program would
 > have to catch the SIGNAL exception at a point where it still
 > had access to the internal data structures that get adjusted
 > during the memory allocation.  Offhand, I don't see why it would
 > so difficult to write such a malloc.  

But what if the signal comes in after malloc returns but before the return
value is assigned to buf?  The problem with asynchronous exceptions is that
EVERY INSTRUCTION might throw.

Jason