--- Hong Zhang <[EMAIL PROTECTED]> wrote: > > > > This is fine at the target language level (e.g. > perl6, python, jako, > > > whatever), but how do we throw catchable exceptions > up through six or > > > eight levels of C code? AFAICS, this is more of why > perl5 uses the > > > JMP_BUF stuff - so that XS and functions like > sv_setsv() can > > > Perl_croak() without caring about who's above them in > the call stack. > > > > This is my point exactly. > > This is the wrong assumption. If you don't care about the > call stack, > how can you expect the [sig]longjmp can successfully > unwind stack? > The caller may have a malloc memory block,
Irrelevant with a GC. > or have entered a mutex, If they're holding a mutex over a function call without a _really_ good reason, it's their own fault. > or acquire the file lock of Perl cvs directory. You > probably have > to call Dan or Simon for the last case. > > > The alternative is that _every_ function simply return > a status, which > > is fundamentally expensive (your real retval has to be > an out > > parameter, to start with). > > This is the only right solution generally. If you really > really really > know everything between setjmp and longjmp, you can use > it. However, > the chance is very low. It is also slow, and speed is priority #1. [snip, snip] > code. The problem is they can not be used inside signal > handler under > MT, and it is (almost) impossible to write a thread-safe > version. Signals are an event, and so don't need jumps. Under MT, it's not like there would be a lot of contention for PAR_jump_lock. -- BKS __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
