in reply to RE: (AgentM) RE (tilly) 2: For all your forking needs..
in thread For all your forking needs..

I think either you or Stevens misunderstands something, and it certainly isn't Stevens.

First of all if you look at Run commands in parallel you will see a use of wait that I would support.

Now let us get at the misunderstanding. What you are quoting Stevens talking about is handling SIGCHILD signals. He is very much correct that you should not do that with wait. The right way to be careful is with waitpid. And indeed the problem is particularly bad in Perl.

I agree with all that.

But that is very different from saying that wait itself should be deprecated. Go back to the example I gave you. You see there that it is used carefully. Signals are not being used to track children, rather you are carefully launching children, keeping track of them, and matching children to reaped processes. So what if you block? The desired behaviour is to block!

But, you say, we should just use a signal handler, right?

Wrong.

Perl's signal handling is not very good. First of all while a signal is being handled, if you get a second one you can dump core. Oops. There are various times in normal operation when a signal can cause you to dump core. Double oops. And Perl's signal handling is based on SysV semantics - not BSD or POSIX.

So even while I agree with everything that Stevens wrote, it is irrelevant since I don't trust signals in Perl. When you don't trust signals then you have to step back and ask yourself, "Do I really want to block?" And if you do, then wait is probably just fine and dandy. When you are talking about signal handlers, it is not good. But for its little niche it is fine.

Now if you disagree with anything I just said, saying it here is the wrong thing to do. Instead get the current development version of Perl, download it, go into the documentation, and start submitting patches to p5p.

  • Comment on RE (tilly) 4: For all your forking needs..

Replies are listed 'Best First'.
RE: RE (tilly) 4: For all your forking needs..
by AgentM (Curate) on Oct 13, 2000 at 06:55 UTC
    That's all fine and dandy, but if you have more than one child, you can lose it in between intermittent calls to wait. Plus, if you use wait, you'll never know WHICH child exited. It will only tell you A child exited. That's not very friendly. For one child, this may be OK, but in most cases, you are dealing with more than one. wait() is NOT OK in any case! waitpid is the ONLY correct way to clean up child processes that are not allowed to become zombies.

    Since Perl (built upon C) is an interpreted language, it will never be good with signals, but the least we can do is to use the better function to clean up the zombies! Using wait instead of waitpid is like using kill instead of sigqueue. Sure, it may work in your certain cases, but in the end, it's simply more beneficial to use the function that

    1. returns more information about the condition of the program
    2. allows more programmer extensibly- queued signals vs. unreliable signals/ blocking perhaps forever on wait at the same time creating a zombie vs. the solution to this exact problem
    In short, i fail to grasp your argument on why anyone should use wait vs. waitpid. if you think it is bad advice to recommend a better function to get more info on the same problem, then that's something I've never heard before. It is my opinion (and that of Stevens) that wait should be replaced in EVERY case with waitpid simply because it will promote better programming practice. The WNOHANG flag bonus is reason enough to replace wait that might block forever if you've lost a zombie! Thanks for the interesting battle of books, but I'll stick with my waitpid.
    AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.
[reply]
      Did you even look at the example I gave?

      I used wait. I knew which child exited. All that the WNOHANG flag could have added is cause to tie up the CPU in a tight loop. And getting the right value would give you reason to load POSIX, which both slows down the code and makes it less portable!

      And for the record I was not telling people to use wait instead of waitpid. I was telling you that you are wrong when you say that wait is deprecated and particularly dangerous.

      Ironically not only is wait not dangerous when used correctly, but your advice all presumes that the programmer will use signals. In fact cautious programmers have read the documentation, see the warnings, and avoid signals in Perl. Your giving any advice based on your theories of how to write good signals is encouraging a practice that is dangerous in Perl.

      Not only that, but the fact that you get a more complex signal handler can cause its own problems. perlipc offers two signal handlers. You and Stevens blast the one that uses wait based on how a safe handler in C should be written. But it is unclear that the waitpid handler is any better. It is more complex, you spend more time in the handler (when any signal will crash you), and the fact that you are assigning to a hash means that eventually you may wind up having a malloc() happen behind your back which would probably cause you to dump core!

      Personally I just skip down to the big WARNING section, take that to heart and avoid both of them!

[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom