in reply to Re^2: Restart Forked Script
in thread Restart Forked Script
Anyway, since this is for Windows, with emulated fork, I'll just pass you some thougths:
There used to be a fantastic page explaining how fork is supposed to work and how it is emulated on Windows, in Perl, using a comic strip, in Mr. Peabody Explains fork(). The domain (temporarily?) just vanished, according to Google's cache: "This page will be going away on 1/14/2006. This is a planned outage, and will last approximately 90 days." So here's hoping it still will come back, one day...
Meanwhile, here's what I think that should be a generic solution, even for Unix: instead of just throwing the kids' ids away, just keep track of them yourself: store them in a complex data structure, and keep an eye on them in the REAP routine. I propose using a hash, that's the easiest for lookup. Here's some untested code, adapted from your original:
my %kids; sub REAP { while((my $deceased = waitpid(-1, WNOHANG)) != -1) { delete $kids{$deceased}; } $SIG{CHLD} = \&REAP; } $SIG{CHLD} = \&REAP; while ($new_sock = $sock->accept()) { if(my $kid = fork) { $kids{$kid} = 1; # parent closes the client since # it is not needed close $new_sock; } else { die unless defined $kid; # if fork failed # the kid's work # ... exit; } }
To kill them all, just work your way through keys %kids. kill apparently can handle them all without loop.
I don't know what signal you're supposed to be using.delete $SIGNAL, keys %kids;
Like I said, I don't expect the REAP routine to ever be triggered on Windows, but I'm not sure. In that case, the %kids hash would only grow over time, but probably not at a huge rate, and thus, would not be a real problem.
|
|---|