> > 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.
Are you serious? Do you mean I can not use malloc in my C code? > > 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. If you don't care about caller, why the caller cares about you? Why the callers need to present their reason for locking a mutex? You ask too much. > > 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. If so, just use C, which does not check nothing. > 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. Show me how to convert SIGSEGV to event. Please read previous messages. Some signals are events, some are not. Hong
