On Sun, 9 Sep 2001, Arthur Bergman wrote: > > Thank you for forwarding that, I've not seen it on-list before. Good to > > know. > > Sarathy claims that all stjmp/longjmp code is exeucted while not holding any mutexes, > so it should be threadsafe. One can note that setjmp and longjmp are not non-mt safe. > But they can be used to do unsafe things.
I know Arthur have seen this, but for the benefits of others: The "Parrot multithreading" thread on news://nntp.perl.org/perl.perl6.internals is talking about this. <snip> Date: Fri, 28 Sep 2001 12:01:44 +0100 From: Alan Burlison <[EMAIL PROTECTED]> Subject: Re: SV: Parrot multithreading? References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <000b01 c1480a$1ee520d0$21000a0a@vogw2kdev> Arthur Bergman wrote: > longjmp in a controlled fashion isn't thread-safe? Or longjmping while holding >mutexs and out from asynch ronous handlers is not > thread-safe? > > Arthur $man longjmp ... ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | MT-Level | Unsafe | |_____________________________|_____________________________| ... It *may* be possible to use longjmp in threaded programs in a restricted fashion on some platforms. However if you use it on Solaris, for example, where we don't commit to it being thread-safe and it breaks - tough. This includes breakage introduced by either new patches or new OS releases, as we haven't committed to it being thread-safe in the first place. mutexes and CVs are one issue, but you can't assume that the code that saves/restores the stack context is thread-safe either. And as for what might happen if you setjmp in one thread and longjmp from a different one - Eeek! Also, generally speaking you shouldn't be using signal handlers in threaded code either. I'm assuming that the overriding aim is portability, in which case threads, signal handlers and longjmp definitely don't mix. -- Alan Burlison </snip> - ask --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
