Re: Wait for background processes to complete

On 2008-01-18 17:30, comp.llang.perl.moderated <ced@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Jan 18, 7:11 am, "Peter J. Holzer" <hjp-usen...@xxxxxx> wrote:
On 2008-01-18 01:34, comp.llang.perl.moderated <c...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:



On Jan 17, 3:12 pm, "Peter J. Holzer" <hjp-usen...@xxxxxx> wrote:
On 2008-01-17 00:52, comp.llang.perl.moderated <c...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

The safest action is an asynchronous wait with a

Before 5.8.0 that was actually unsafe. But while it is now safe in
perl

Huh.. just for clarity, here's what I wrote:

use POSIX ":sys_wait_h";
$SIG{CHLD} = \&REAPER;
# now do something that forks...
...
sub REAPER { 1 while waitpid(-1, WNOHANG)) > 0; }

In fact, historically, there's a clear recommendation to tight-loop
exactly as shown because you may lose signals occurring in
near concurrency if you don't.

The problem with this approach is that until 5.8.0 (when "safe signals"
were introduced), the REAPER function would be called as soon as the
signal arrived regardless of what the perl interpreter was doing at the
time - there was a very real risk that this would crash the perl
interpreter (in a real world application which forked about 50,000 to
100,000 times a day, the parent process would crash every few days with
perl 5.6.0). In C the POSIX standard explicitely states which functions
are safe inside a signal handler (and the rest has to be considered
unsafe), but for perl no such list existed (so everything has to be
considered unsafe). In perl 5.8.0, the "real" signal handler only notes
that a signal arrived, and perl will than invoke sub REAPER when it can
safely do this (which may be quite some time later).

Or are you suggesting that an explicit wait on each of the child
processes would somehow be safer...

Avoiding signal handles was indeed "somehow safer" before 5.8.0,
because signal handlers were fundamentally unsafe (and arguably broken)
in perl.

Hm, I thought I recalled that, even with
Perl's broken pre-5.8 signal handling, the
issue was most likely to surface with op's
not on POSIX's safe list.

One function not on POSIX's safe list is malloc. And since just about
anything in perl is dynamically allocated ...

Something like 'waitpid', which is on POSIX's safe list, in a simple
loop was unlikely to cause a problem.

waitpid probably wasn't a problem. The loop might have been. Simply
calling the reaper function (which needs to allocate a call frame) might
have been. In the program I mentioned, a reaper function deleted an
entry from a hash - this definitely was a problem.


You're right, a asynchronous wait would need to
save child pids and loop until they're reaped.

Yes. But why would you want to do that if it can be done a lot simpler
and more straightforward?


Yes I agree that's probably true here but, as you mention, you'd have
to check for -1 because the process was reaped, stopped, or terminated
by some signal for instance. And, if you're concerned about zombies,
you really need to keep a list of pids to wait on.

Zombies are not a concern in this case. When you post a followup to a
question of an obvious perl beginner, please try to provide a solution
to his problem. A solution to a completely different problem will just
confuse him, especially, if you don't say that it is a solution for a
completely different problem.


To me the solutions are very close modulo the signal function setup.

The signal function setup is the difference, yes. For the OP's problem a
signal handler is not only not needed, but does nothing at all to solve
the problem.

hp
.

Relevant Pages

  • Re: Wait for background processes to complete
    ... exactly as shown because you may lose signals occurring in ... signal arrived regardless of what the perl interpreter was doing at the ... and perl will than invoke sub REAPER when it can ... calling the reaper function might ...
    (comp.lang.perl.misc)
  • Re: Wait for background processes to complete
    ... Before 5.8.0 that was actually unsafe. ... But while it is now safe in perl ... The problem with this approach is that until 5.8.0 (when "safe signals" ... the "real" signal handler only notes ...
    (comp.lang.perl.misc)
  • Re: OpenVMS 8.1 ships
    ... Perl has about ... only modifications to one DCL script and one Perl script ... signals with a home-grown implementation based on the undocumented ... CRTL bug on 7.x systems that precludes the ability to call ...
    (comp.os.vms)
  • FAQ 8.13 How do I trap control characters/signals?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... are documented in "Signals" in perlipc and the section on ``Signals'' in ... Asked Questions" or FAQ for short. ...
    (comp.lang.perl.misc)
  • FAQ 8.13 How do I trap control characters/signals?
    ... This message is one of several periodic postings to comp.lang.perl.misc ... from the documentation provided with Perl. ... are documented in "Signals" in perlipc and the section on ``Signals'' in ... Asked Questions" or FAQ for short. ...
    (comp.lang.perl.misc)