quinet@xxxxxxxxxx (Raphael Quinet) writes: > On Wed, 08 Nov 2000, Ludovic Poitou <ludovic.poitou@xxxxxxxxxxxxxx> 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 <pvt.benkovsk@xxxxxxxxx> 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
