On Wed, Aug 05, 2009 at 03:33:34PM +0100, Dave Mitchell wrote: > On Wed, Aug 05, 2009 at 04:02:54PM +0200, Vincent Pit wrote: > > Thanks for this. > > > > > On Wed, Aug 05, 2009 at 03:16:05PM +0200, Vincent Pit wrote: > > >> > The thing that puzzles me is that is doesn't explode on 5.8.x. > > >> > > >> I've no idea about why it works with 5.8, nor why the pointer table is > > >> flushed for the fork emulation but not for threads. > > > > Now I know why it doesn't crash on 5.8 : I explicitely disabled > > Variable::Magic thread safety for those. > > > > > That was a change to threads.xs a while ago. Originally neither kept the > > > table around - its an expensive use of memory (at least 12 bytes per SV > > > etc per thread). > > > > threads.pm manually destroys the pointer table after the new interpreter > > is created. It should theorically be fine to just shove a > > ptr_table_free(PL_ptr_table) right after the call to perl_clone_using() in > > PerlProcFork(). The pointer table has to be alive when CLONE is called, > > not after. > > Ah, the penny drops! > > The real issue is that in perl_clone_using(), it frees the ptr_table > *before* calling the CLONE methods. > > With b0b93b3c773176a99136baa97661d11503277415, I've fixed > perl_clone_using() to free it afterwards; then I've backed out the > win32/perlhost.h change. > > I'll be pushing this into maint in a moment. > > I wonder: for existing 5.10.0 users, whether Variable::Magic could > test for a null PL_ptr_table before calling sv_dup? I don't know whether > that would ameliorate the problem, or whether you're already going to > crash and burn due to skipping the dup??? PS can someone confirm ASAP that GitLive-maint-5.10-1727-g02784d7 or later fixes the V::M fork issue on windows? Thanks. -- The Enterprise's efficient long-range scanners detect a temporal vortex distortion in good time, allowing it to be safely avoided via a minor course correction. -- Things That Never Happen in "Star Trek" #21Thread Previous