http://qs1969.pair.com?node_id=79665


in reply to Have children maintain themselves or main script maintain children.

It depends on exactly the inisialisation the children have to do. If the children have to make a database connection then you'll want to prefork them as in the second option. If the children should just be clones of the parent (ie can start work immediately after forking) then the first would be most appropriate.

That said just in just about any serious application you'll want to do some initialisation in the children so you'll want to prefork them, and to keep them alive for maximum speed.

You should make sure your children don't live forever though so that any memory can be reclaimed and they can go back to sharing all their pages with the parent. Maybe they should die after 100 uses or 60 minutes.

This is exactly how apache works - preforking its children and then they kill themselves after a set time. However apache keeps a dynamic number of children depending on the work load - a minimum number up to a maximum number.

Top tip: Don't use signals in the parent to catch SIGCHLD (as demonstrated in The Perl Cookbook) otherwise you'll miss some of your children dieing, just use wait. Set in non-blocking if you must but you want to try to do the absolute minimum in the parent so it is always alive to spawn more children.

Replies are listed 'Best First'.
(tye)Re: Have children maintain themselves or main script maintain children.
by tye (Sage) on May 11, 2001 at 14:06 UTC

    Also, try to design the parent so it can exec itself every few hours or days for the same reasons that you don't want the children to live forever.

            - tye (but my friends call me "Tye")
Re: Re: Have children maintain themselves or main script maintain children.
by the_0ne (Pilgrim) on May 11, 2001 at 18:44 UTC
    Top tip: Don't use signals in the parent to catch SIGCHLD (as demonstrated in The Perl Cookbook) otherwise you'll miss some of your children dieing, just use wait. Set in non-blocking if you must but you want to try to do the absolute minimum in the parent so it is always alive to spawn more children.

    Actually the way we wrote the code is to use a combination of SIGCHLD and also waitpid so not to miss any children dieing. But your concern over the code concerns me, why do you say not to use SIGCHLD like the The Perl Cookbook does? We haven't run this script yet for a long period of time because there's still some things that need to be done, but so far it seems to be pretty good at cleaning things up, at least children-wise.
      There are several disadvantages to installing a SIGCHLD handler

      • Signals aren't reliable so you may not get one for every child expiry. Using waitpid in a loop will help here.
      • You can get SIGCHLDs from your children when they haven't died (eg your child gets sent a SIGSTOP - the parent will get a SIGCHLD)
      • You can get SIGCHLDs from perl operations like open "|.." and backticks if you are unlucky which can confuse things.
      • Unreliable signals are evil!

      Some of the examples in The Perl Cookbook have the correct waitpid in a loop in the SIGCHLD handler, but some don't (for instance the section on a preforking daemon).

      Personally I would ignore SIGCHLD and make the parent wait() for the children to die. It will be nicely blocked (ie not using any excess CPU) until it needs to do something (ie make more children).

        Thanks for the explanation. We HAVE run into your first bulletpoint. We had some children come back that gave us the pid instead of 0 or -1 and had to work around that. So, I can understand your explanation there.

        for instance the section on a preforking daemon

        I'm almost positive (I don't have the book here with me today.) that the preforking daemon is the major example we used and you're right, it does not have the waitpid. We got lucky and found that in a post on good old PM.

        Personally I would ignore SIGCHLD and make the parent wait() for the children to die. It will be nicely blocked (ie not using any excess CPU) until it needs to do something (ie make more children).

        gr0k and I were just talking about that. I think my weekend project has just shown up. :)

        Thanks to everybody that has helped out with this node.