Re: Possible bug: Race condition when calling external commands during trap handling

[Linda Walsh]

Andreas Schwab wrote:

> Bob Proulx <bob@proulx.com> writes:
>
> > And lastly I will comment that you are doing quite a bit inside of an
> > interrupt routine.  Typically in a C program it is not safe to perform
> > any operation that may call malloc() within an interupt service
> > routine since malloc isn't reentrant.  Bash is a C program and I
> > assume the same restriction would apply.
>
> Traps are executed only at command boundaries.  Executing them in a
> signal handler would make them completely unusable, of course.
>
> Andreas.

---
        But a trap HAS to be executed in the trap handler
to reset it self, otherwise you risk losing a signal.

        As soon as you exit your trap handler,
your trap handler had better already be in place.
If it isn't and trap comes in before you catch it,
you've lost it.

the "perlipc" manpage explains some of the details
behind this problem.  Their suggested handler:

           use POSIX ":sys_wait_h";
           sub REAPER {
               my $child;
               # If a second child dies while in the signal handler caused by 
the
               # first death, we won't get another signal. So must loop here 
else
               # we will leave the unreaped child as a zombie. And the next time
               # two children die we get another zombie. And so on.
               while (($child = waitpid(-1, WNOHANG)) > 0) {
                   $Kid_Status{$child} = $?;
               }
               $SIG{CHLD} = \&REAPER;  # still loathe SysV
           }
           $SIG{CHLD} = \&REAPER;
           # do something that forks...

---
I think it was sysV compat libs that are unsafe (you have to reset
handler each signal)...