On Fri, May 12, 2000 at 05:43:20PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> * The Gimp continues and the status of second plug-in is never
> collected, so this creates a zombie.
> If you are sure that all kernels of the systems that Gimp supports
> will re-deliver the second SIGCHLD signal immediately after the signal
> handler returns,
These kernel exists, but most likely gimp won't compile on them
anyway. There is a large body of programs relying on these
marginally-working-POSIX signals (bash or perl for example), and breaking
the expectations of signal blocking would most likely break these
programs. However, the bash tries to workaround bugs in various versions
of waitpid....
> status of the second plug-in. But I do not think so; that's why I
> suggested to call waitpid() outside the signal handler, because then
> you avoid the race condition.
This would indeed be the most safe solution.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
