At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
> > 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.
Yup, and we can use platform-specific exception handling mechanisms
as well, if there are any. Except...
>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.)
You hit this. And we can't universally guarantee that it'll work, either.
>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
If we're going to do this, and believe me I dearly want to, we're
going to be yanking ourselves out a bunch of levels. We'll be setting
the setjmp in runops.c just outside the interpreter loop, and yank
ourselves way the heck out. It's that multi-level cross-file jumping
that I really worry about.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
