the_0ne has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks. This time I have more of a (which is the most resourceful way) type of question instead of help with code. I have a script that forks off some children. Now, the way it works is those children fork off, run and while they are processing the calling script is looking for their demise. Once they (pass away) I have a sleep look for a certain time period to restart each child separately again. So, you have children that come and go and then after a few seconds re-spawn.

Now, to the other way a co-worker and I were talking about running the script. The way I could have written this is to have the children spawn from the main script and then have the children maintain themselves by running forever and watching their own timing with sleep. So, now if I fork off 5 children, they won't go away until I say instead of dieing and re-spawning like the first paragraph.

My question is which way is more resourceful? Is it good for the children to die and re-spawn like that or would it be better to have them stay alive forever until forced to die and maintain their own set of code?

Both the co-worker gr0k and I are somewhat new to forking and were curious on what the monks would think about this.

Thanks Again Monks.
  • Comment on Have children maintain themselves or main script maintain children.

Replies are listed 'Best First'.
Re: Have children maintain themselves or main script maintain children.
by dws (Chancellor) on May 11, 2001 at 09:57 UTC
    My question is which way is more resourceful? Is it good for the children to die and re-spawn like that or would it be better to have them stay alive forever until forced to die and maintain their own set of code?

    This depends on what your children are doing, and what their memory usage patterns are. Perl does garbage collect, but it does so within a memory arena that grows but never shrinks. You might find that you need to kill and re-spawn your child processes just to be resource friendly.

    This problem appears in a number of different forms, and many words have been written on how to write servers that pre-spawn (and recycle) their children. The Perl Cookbook devotes part of a chapter to it, and merlyn has written several Web Techniques articles that cover that ground.

[reply]
      Actually a lot of the code came straight from The Perl Cookbook and then we modified it greatly because it wasn't doing what we wanted to the extent we wanted. I haven't checked out many of merlyn's articles on forking though. I'll have to do that.
[reply]
Re: Have children maintain themselves or main script maintain children.
by ncw (Friar) on May 11, 2001 at 14:00 UTC
    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.

[reply]

      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")
[reply]
      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.
[reply]
        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).

[reply]

Back to Seekers of Perl Wisdom