Front page | perl.perl5.porters |
Postings from January 2011
Hello Simon (and p5p),
Am 03.01.2011 22:32, schrieb Simon Wistow:
> On Wed, Dec 29, 2010 at 04:35:24PM +0100, Max Maischein said:
>> 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 $$.
>
> For what it's worth Whatif.pm (which fakes reversible computing using
> fork() and more than a touch of crack) explicitly modifies $$ as part of
> its smoke and mirrors and, IIRC, it stole the code to do that from
> PPerl.
For Whatif.pm, the change could be trivial (but I can't conveniently
test it, as Whatif doesn't play nice with the Win32 fork emulation), by
making $$ read-write (at the price of disconnecting it from getpid()):
BEGIN {
my $pid = $$
*$ = \my $pid;
};
and removing the XS part:
# some shennanigans, knicked from PPerl
if ($] > 5.006001) {
setreadonly('$', $dollardollar);
} else {
$$ = $dollardollar;
}
eval { $whatif->() }
...
(thereby even obviating the need for XS in Whatif). I'm not sure how
that affects access to $$ from XS.
PPerl can be "easily" fixed by moving the setting of $$ in
pperl.h.header out of the setup_chunk() routine up to where *ARGV is
localized (as localizing $$ still works). PPerl seems somewhat derelict,
as its installation process is broken for Win32 and there are some
long-term open tickets. This is why I've refrained from actually
implementing the change so far.
If the seemingly easy change to make $$ read/write and disconnected from
getpid() is enough, I would like to dewarnock my patch and see at least
some smoke reports and BBC reports :)
-max
Thread Previous
|
Thread Next