Front page | perl.perl5.porters |
Postings from January 2001
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... :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next