> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The issue of 'which thread' comes in with signals. We can tell
DS> with real async events, since they'll have thread ownership tags
DS> on them if we care, but we can't do that with signals, and then we
DS> have the issue of "whic
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 dea
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
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 librar
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'
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 stu
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
> >
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 curren
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:
> >
"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 th
[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 st
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 i
12 matches
Mail list logo
