Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Keeping children alive persistiently, intelligently

by kyle (Abbot)
on Feb 08, 2008 at 20:13 UTC ( [id://667057]=note: print w/replies, xml ) Need Help??


in reply to Keeping children alive persistiently, intelligently

This sounds like a job for POE, but I don't know enough about that module to say for sure.

If I were writing this, I'd be strongly tempted to make each child into an object. You could stash within it $params and all the other state that you're trying to hold and modularize all the behavior you want them to have. Each child object in the parent would know the PID of the child process, the parameters it started with, how many times it has died, etc.

  • Give the child object a DESTROY method that kills the child process. This way when the parent exits, the children go with it.
  • The parent can still wait for something to die and tell the relevant child to restart itself.
  • The child can fork and then sleep to get the delay you want.

Something like:

my @child_info; foreach my $params (@params_for_children) { my $child = Foo::Child->new( params => $params ); $child->spawn(); push @child_info, $child; } while ( my $pid = wait() ) { last if $pid = -1; my $exit_status = $?; my ($poor_dead_child) = grep { $_->{pid} == $pid } @child_info; $poor_dead_child->fyi_you_died(); $poor_dead_child->spawn(); } package Foo::Child; sub new { my $class = shift; my $self = { @_ }; return bless $self, $class; } sub DESTROY { kill 'TERM' => shift->{pid} } sub fyi_you_died { shift->{death_toll}++ } sub spawn { my $self = shift; my $pid = fork; die "Can't fork: $!" if ! defined $pid; if ( $pid ) { $self->{pid} = $pid; return; } else { sleep ... if $self->{death_toll} > ...; do_child_stuff( $self->{params} ); die; } }

This is just a sketch, but hopefully you get the idea. Having written all this, I'm now guessing that someone will come along with a much better CPAN module I've never heard of.

Update: Upon further consideration, I'm not sure this is such a hot idea. Each child is a copy of the whole, so each has a copy of all the child objects. As soon as one of them dies, it's going to shoot all the other ones in their destructors. Oops. You could still have them all manage themselves except for the DESTROY methods. In that case, the parent would have to kill them all manually in an END {} block.

Update 2: Another thought. You could write DESTROY this way:

sub DESTROY { my $self = shift; if ( $$ == $self->{parent_pid} ) { kill 'TERM' => $self->{pid}; } }

Then you have spawn note the parent PID before it forks

sub spawn { my $self = shift; $self->{parent_pid} = $$; my $pid = fork; # ...

Replies are listed 'Best First'.
Re^2: Keeping children alive persistiently, intelligently
by Hercynium (Hermit) on Feb 08, 2008 at 20:45 UTC
    Your OO approach appeals to me - I've been on somewhat of an OO-FP kick lately - and in your code I think I see a potentially clean, maintainable way to implement the required features.

    BTW, regarding memory worries: Look for my response to zentara. One of the reasons I'm using fork() is because the OS can do some wonderful tricks with it to keep memory usage down.

    I appreciate all the thought you've put into this. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://667057]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (2)
As of 2024-04-26 04:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found