[EMAIL PROTECTED] (Raphael Quinet) writes:

> On Wed, 08 Nov 2000, Ludovic Poitou <[EMAIL PROTECTED]> wrote:
> > Here's the results I got with your test program on Solaris 8, OSF1,
> > HP-UX, AIX.
> [...]
> > Results on Solaris 8:
> > sigchld handler was called before waitpid (no status)
> [...]
> > Results on OSF1- V4.0 True64 - alpha
> > sigchld handler was called before waitpid (no status)
> [...]
> > Results on HP-UX B.11.00 E 9000/715
> > sigchld handler was called before waitpid (no status)
> [...]
> > Results on AIX 3.4
> > sigchld handler was called before waitpid (no status)
> 
> On Wed, 08 Nov 2000, Jarda Benkovsky <[EMAIL PROTECTED]> wrote:
> > FreeBSD 3.4-STABLE:
> > sigchld handler was called before waitpid (no status)
> > 
> > IRIX 6.5 IP22:
> > waitpid got the status before sigchld handler was called
> 
> 
> Thanks Ludovic and Jarda for these very interesting results!
> 
> According to these results, the signal handlers of the plug-ins are
> compatible with the following systems:
> - Linux 2.2.x
> - IRIX 6.5
> 
> But since May (when the signal handlers were changed, if I remember
> correctly), the five plug-ins "screenshot", "gz", "bz2", "mail", and
> "url" had no chance to work well on the following systems:
> - Solaris 2.6 and 8
> - OSF1
> - HP-UX 11.x
> - AIX 3.4
> - FreeBSD 3.4
> 
> ... and there was no bug report about this in the database!
> 
> Maybe we should all do our "mea culpa" and test a bit more seriously
> especially on non-Linux platforms, now that 1.2 is just around the
> corner.

Nope, it's just me with the "mea culpa" thing.

The

  gimp_signal_private (SIGCHLD, gimp_plugin_sigchld_handler, SA_RESTART);

call is just to restart system calls interrupted by SIGCHLD.
The signal handler does nothing more than removing the zombie.

But as all plug-ins which fork() also want to fetch waitpid()'s
return values.... EEEEK

I'll change the above line to 

  gimp_signal_private (SIGCHLD, SIG_DFL, SA_RESTART);

and we're done :)

Your patch is cool anyway because it does proper return value checking
and other right things (TM). I'll apply a modified version.

> By the way, could someone who works on the OS/2 port have a look at
> the __EMX__ part of the code in plug-in/common/gz.c?  If possible,
> after applying gimp-quinet-20001108-1.patch.gz that I uploaded to
> ftp.gimp.org.  That code looks very suspicious to me.  It contains a
> call to sleep(2) instead of using waitpid() for getting the output of
> the child process.  The four other plug-ins are using waitpid() as
> expected.  If the call to sleep() is the only way to get gz to work,
> then the four other plug-ins should be changed (with some comments
> explaining the problem).  If the other plug-ins work, then why is
> there such an ugly hack in gz.c?

No idea... Does GIMP still run on EMX at all? Did anybody try this
recently?

Thanks to all for the debugging.

bye,
--Mitch

Reply via email to