[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.


  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

Thanks to all for the debugging.


Reply via email to