| Subject: | NFSLock bug when using fork() |
| Date: | Wed, 22 Jul 2009 21:09:30 -0400 |
| To: | bug-File-NFSLock [...] rt.cpan.org |
| From: | Todd Foggoa <todd.foggoa [...] gmail.com> |
If the parent grabs a lock and then forks a child, the parents lock is
incorrectly released when the child exits because there is no check
for PID in the DESTORY function. I noticed this problem for exclusive
locks, there maybe some more logic required for shared locks. Also,
note this still works with the newpid function which, if used, will
allow the child to release the lock becuase the "lock_pid" is changed
to the child pid in the newpid function.
This was seen in the latest 1.20 version of the NFSLock module:
Exisiting code:
sub DESTROY {
shift()->unlock();
}
Fixed code:
sub DESTROY {
my $self = shift;
# maybe some extra checking is needed here for shared locks ?
if ($self->{lock_pid} == $$) {
$self->unlock();
}
}
Here is a rough code example highlighting the problem:
$lock = File::NFSLock->new("lockfile", LOCK_EX, 30, 60));
# some processing
$child = fork();
if ($child) {
# parent
# some processing
wait();
} else {
# child
# some processing
exit 0; # <<<<<<< lock is wrongly released here
}
# some processing
$lock->unlock();
Thanks,
-Todd