Front page | perl.perl5.porters |
Postings from August 2009
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??? -- In England there is a special word which means the last sunshine of the summer. That word is "spring".Thread Previous | Thread Next