-
Notifications
You must be signed in to change notification settings - Fork 2
Description
This is probably a design decision. But as this is not documented, I lean to consider it a bug / limitation.
The current implementation of Scope::Guard does not have the notion of the main process which created the guard.
This could lead to multiple execution of a guard, and most of the time this is probably not what we want/expect.
Here is a sample proof of concept showing the limitation
#!perl
use v5.32;
use Scope::Guard;
sub test {
my $g1 = Scope::Guard->new(
sub {
say qq[guard 1 done from $$];
}
);
if ( my $pid = fork() ) {
say q[Parent: ], $$, q[ kid: ], $pid;
sleep 2;
} else {
sleep 1;
say q[kid leaving];
exit;
}
say q[done];
}
test();Output:
> perl test.pl
Parent: 11887 kid: 11888
kid leaving
guard 1 done from 11888
done
guard 1 done from 11887
Most of the time these kinds of fork would happen from unpredictable locations while running some extra code, while holding a guard.
Adding a PID protection is pretty forward, and I can gladly provide a fix for it.
But before I'm curious to know your point of view, and if you also think this should be the default behavior.
Note that this could lead to main behavior change.