Front page | perl.perl5.porters |
Postings from December 2010
Hello,
I've already asked on #p5p and nobody (present) came up with a reason
why this should be done, so attached is a patch.
Perl fetches at program startup the value of getpid() and stores it in
$$. When the process (pseudo-)forks via PerlProcess_fork(), the
information is updated.
This is a bug opportunity, because if XS calls fork(3) or an embedding
application calls fork(3), Perls notion of $$ and the value of getpid()
can go out of sync, unless the C code takes special care to update $$.
The attached patch eliminates some duplicated code and turns $$ into a
magical variable that always fetches its value from PerlProc_getpid().
It Passes Tests on My Machine (Win32+gcc), or rather, it doesn't seem to
cause failures that didn't happen before.
I'm not sure what the downsides to this would be, except the small speed
hit. Existing C/XS code that calls fork(3) might already do the
SvREADONLY_off(dollardollar);
sv_setiv(dollardollar,getpid())
SvREADONLY_on(dollardollar);
dance to update Perl with the new pid. This should still work, except
that this value will never be read out of that variable. At least it
still compiled and did not crash during my tests in win32_start_child().
If the existing code already (properly) calls S_init_postdump_symbols()
(or whatever one is supposed to call after fork(3) in the child), then
nothing bad should happen either.
-max
Thread Next