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

[Joe Buck]

My example:
> >   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.

Josh writes:
> 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).

No, you are thinking of malloc corruption, which is not the issue here.
Assume a perfect implementation, with proper critical regions in malloc
(sighold/sigrelease or the like).  If buf is in memory -- more likely if I
write something like

	struct_p->buf = malloc(buf_size);

there is still a window between the return of malloc (the end of any
critical region) and the assignment of the result.  Even if buf is a
register, we may still need a reg-to-reg move, and the signal could
come just before the move.

As Mike Stump likes to point out, one still might be able to use async
exceptions in particular cases if extreme care is taken.