On Tue, Aug 04, 2009 at 03:49:29PM -0600, Curtis Jewell wrote: > Can I request that this fix (or a better-implemented fix for this bug) > go in, if not before 5.10.1-RC1, soon afterwards, please? I would be extremely reluctant to put this in RC1, and if it's not in RC1, it's not going to be in 5.10.1. > I'm given to understand (talk to kmx about that to be sure) that this > affects dependencies of Catalyst::Runtime (among others) on Win32. [ > http://cpants.perl.org/dist/used_by/namespace-clean and > http://cpants.perl.org/dist/used_by/Variable-Magic ] > > --Curtis Jewell > > Mon, 03 Aug 2009 07:03 -0700, "kmx via RT" <perlbug-followup@perl.org> > wrote: > > Hi, > > > > I have investigated this issue further and found out that it is present > > also in the latest perl5 blead. > > > > Based on Vicent's post above I have tried this patch to win32/perlhost.h > > > > - PerlInterpreter *new_perl = perl_clone_using((PerlInterpreter*)aTHX, 1, > > + PerlInterpreter *new_perl = perl_clone_using((PerlInterpreter*)aTHX, 1 > > | CLONEf_KEEP_PTR_TABLE, > > > > and IT SOLVES the described fork issue but I am not able to say that > > this is the right way for fixing it. So if I understand it correctly, Variable::Magic has been made to work under threads by making use of the thread's ptr_table, which is kept around after a new thread is created. However, fork() under windows is emulated by using the same threading mechanism that threads.pm uses but it doesn't keep the ptr_table around (and never has). Variable::Magic can't distinguish between a thread clone and a fork clone, and assumes that the ptr_table is always around, and thus explodes. The thing that puzzles me is that is doesn't explode on 5.8.x. -- Never work with children, animals, or actors.