Front page | perl.perl5.porters |
Postings from November 1999
On Fri, 19 Nov 1999 19:10:09 EST, Rob Cunningham wrote:
>I am amazed that people are arguing over whether to include the patch based on
s/people/Ilya/
>the number of ops. Threaded perl as currently distributed is broken in a way
>that is fixed by this patch.
>
>Actually, I've done some moderate testing of Brian's patch, and so far it
>appears to fix the problems that I've experienced with threaded perl. If
>someone, someday wants to make a faster fix, go ahead. But please merge this
>with the official perl until the day that someone else has the time to speed
>it up. I want to do more extensive testing of threaded perl on an offical
>developers release, and believe that wider distribution will be benenficial.
>
>In summary, here's our approach:
>Step 1: Make it work.
"Make it work right."
>Step 2: Make it work fast.
>
>We've done step one, because we _need_ it to work. Anyone else is welcome to
>do step two.
The work is much appreciated, despite appearances to the contrary.
I haven't had time to look closely, but I think the biggest problem
with the patch is that it takes a less than perfect approach (which
is perfectly understandable, given the obscurity of the perl source
code in general and the RE engine in particular).
* match variables are not the only threading bombs in REs (things
like /(?{ ... })/ and utf8 patterns /\pM{IsAlpha}/ also carry
data that should be made thread local, or rather, scratchpad-local)
* match variables don't work for other things for the same reason
they break under threads, and the patch doesn't fix those areas
(recursion and closures are two of them)
As has been mentioned here before, the better approach would be to make
PMOPs allocate scratchpad entries to carry their data. Those get cloned
both under USE_THREADS and the above situations, which means that
approach would make for a more general fix to the problem.
Thanks.
Sarathy
gsar@ActiveState.com
Thread Previous
|
Thread Next