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
[EMAIL PROTECTED] wrote:
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
"Deven T. Corzine" wrote:
On Sat, 23 Dec 2000, Graham Barr wrote:
This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is
func($x{1}{2}{3})
at this point you do
Yeah, you're thinking along the same lines as I was. Unfortunately, there
needs to be consensus about whether this behavior should be changed before
it can be implemented -- any idea how to make that come about?
Deven
On Sun, 21 Jan 2001, David L. Nicol wrote:
"Deven T. Corzine" wrote:
At 06:10 PM 1/21/01 +, Alan Burlison wrote:
[EMAIL PROTECTED] wrote:
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
Dan Sugalski wrote:
*) If, and *only* if, a variable is marked as shared, then its vtable
function pointer is replaced with a threadsafe version. (Or, rather, a
pointer to the 'use in case of threads' table--strictly speaking it doesn't
have to do any locking, but that would be pretty
At 10:00 PM 1/21/01 +, Alan Burlison wrote:
Dan Sugalski wrote:
*) If, and *only* if, a variable is marked as shared, then its vtable
function pointer is replaced with a threadsafe version. (Or, rather, a
pointer to the 'use in case of threads' table--strictly speaking it doesn't
Dan Sugalski wrote:
I'm torn between doing that and not, since firing up a second OS-level
thread can add some overhead that we might not need with the "set a flag
and check on op boundary" setup. I know that VMS won't kick over to the
slower fully threadsafe version of its runtime libraries
At 05:02 PM 1/21/01 +, Alan Burlison wrote:
Kinda both. Perl5 threads are irredeemably broken, and IMHO should be
excised from the source as soon as possible - leaving them in only gives
the mistaken impression that they might actually work some day. The
MT-unsafe behaviour of the current
At 11:04 PM 1/21/01 +, Alan Burlison wrote:
Dan Sugalski wrote:
I'm torn between doing that and not, since firing up a second OS-level
thread can add some overhead that we might not need with the "set a flag
and check on op boundary" setup. I know that VMS won't kick over to the
On Sun, 21 Jan 2001 17:28:49 -0500, Dan Sugalski wrote:
The issue of 'which thread' comes in with signals. We can tell with real
async events, since they'll have thread ownership tags on them if we care,
but we can't do that with signals, and then we have the issue of "which
thread" to deal
11 matches
Mail list logo
