> Okay, i've thought things over a bit. Here's what we're going to do
> to deal with infant mortality, exceptions, and suchlike things.
>
> Important given: We can *not* use setjmp/longjmp. Period. Not an
> option--not safe with threads. At this point, having considered the
> alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement is not very accurate. The real problem is
setjmp/longjmp does not work well inside signal handler.
The thread-package-compatible setjmp/longjmp can be easily implemented
using assembly code. It does not require access to any private data
structures. Note that Microsoft Windows "Structured Exception Handler"
works well under thread and signal. The assembly code of __try will
show you how to do it.
However, signal-compatible will be very difficult. It requries access
to ucontext, and most of thread package can not provide 100% correct
ucontext for signal. (The thread package may have the right info, but
the ucontext parameter may not have the info.)
My basic suggestion is if we need convenient and fast C-based exception
handling, we can write our own setjmp/longjmp in assembly code. The
functionality will be exported as magic macros. Such as
TRY {
...
} CATCH (EBADF) {
...
} CATCH (ENOMEM) {
...
} END;
Hong
