develooper Front page | perl.perl5.porters | Postings from January 2001

Re: Does perl really need to use sigsetjmp? (18% performancehit)

Thread Previous | Thread Next
Dan Sugalski
January 21, 2001 13:19
Re: Does perl really need to use sigsetjmp? (18% performancehit)
Message ID:
At 05:02 PM 1/21/01 +0000, 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 eval mechanism when used with threads
>is just one of the reasons why they are so broken.

Well, that and the regex match variable nonsense are the two biggies. All 
the rest I know of are the "shoot yourself in the foot types". On the other 
hand we only really need one...

>As for perl6, there has been discussion of using the same sort of
>brokenness there too.  The only model that seems to make sense to me is
>the interpreter per thread model, with new language syntax for shared
>state, such as variables visible to more than one interpreter.  One
>advantage of the vtbl model being suggested is such things become much
>easier to do.

Okay, here's what perl 6 will provide from a thread standpoint.

*) Starting a new thread in perl starts a new interpreter. You may get a 
clone of the current interpreter state ($/ and suchlike things, at least 
the ones that remain), and possibly the variable state.

*) 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 stupid) Multiple threads 
can access the shared data (the thread that shared it and any threads it 
spawns). We do no user-level locking, and if the low-level locking that the 
vtable functions do to ensure we don't core dump is really expensive, well, 
too darned bad)

*) POSIX-style locking and condition stuff will be provided and act on 
shared data. (Yeah, it kinda sucks in some ways, but it's about as 
low-level as you can get and still provide the needed functionality, and 
other stuff can be built on top of it)

*) We *will* yank out any promises of what threads signals (or any async 
event) fire off in. I really, *really* want to toss the promise of being 
able to die from within a signal handler that catches a real signal, but I 
don't know that Larry will go for that. (Expecting sane shutdown when you 
essentially puke from within an interrupt handler's always struck me as a 
semi-odd thing, though I understand the utility) to some extent

* We may put in a mechanism to direct an interrupt at a particular thread 
(and probably will have to to preserve the 'die from a signal handler' 
stuff, but that'll only work for perl-generated events and non-fatal 
synchronous signals (of which there are very few))

I don't know what Larry will want from a language perspective, but this is 
what he'll get from the core engine. I think this is the smallest safe set 
of things we can do, and I'm reasonably sure that everything else anyone 
might want can be layered on top, albeit slowly in some cases.

Followups are best sent to the perl6-internals list, though if someone 
thinks I'm all wet on some spot, do feel free to let fly... :)


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About