Alan Burlison <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>
>> Why is setjmp() not thread safe? (assuming that two threads are
>> not using the same jmp_buf which would be just dumb).
>>
>> As far as I can see setjmp() just needs to save the machine state
>> and longjmp() just restore it. SPARC register windows make that messy
>> but still possible.
>
>Here's the word from the man who knows:
>
>> They are designed to work as advertised, but they are MT-usafe in
>> principle.
>>
>> They are MT-unsafe because if you use siglongjmp(), say, from a signal
>> handler, then you have no idea where the application was executing when
>> the signal occurred. It may have been holding a mutex or it may have
>> been asleep in a cond_wait(). The siglongjmp leaves the state of the
>> application undefined with respect to the locks that are held.
So the "gloss" is that (sig)longjmp() does not understand locks.
I can understand that. If all goes according to plan perl will no longer
longjmp() out of signal handlers. So the issue becomes other places
where locks can be held. With the possible exception of stdio, perl
is in a position to "know" about those and undo them as part of
its stack unwinding.
>>
>> The short answer is *never use them* in a multithreaded application.
But the short answer (while it may suffice for perl6) is no use to me
as a perl5 maintainer.
--
Nick Ing-Simmons
