[severely trimmed] On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote: > On Fri, 13 May 2005, Hervé Kergourlay wrote: >> Seán C. Farley a écrit : >>> On Thu, 12 May 2005, Seán C. Farley wrote: >>>> On Thu, 12 May 2005, Hervé Kergourlay wrote: >>>>> 4) wait() API >>>>> >>>>> 2 problems, the first is a ECHILD error on a wait call after a fork >>>>> fork The code is generic for most of unix system. Is there any >>>>> specific problems to manage the fork and wait APIs ? the second >>>>> problem with calls is a blocking wait() call in the same condition >>>>> but this time the son process is finished but the wait call in the >>>>> father stays blocked, again it's a generic Unix code >>>>> >>>>> If there is no evidence, ask me for more informations >>>> >>>> The second problem sounds like what I am encountering >>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=77818) with zsh for my >>>> shell. You did suspend (sigsuspend()) SIGCHLD before the fork? By >>> >>> >>> Ah ha! I see the problem that has been causing me this problem and >>> probably you too. Signal suspensions (only these?) are not being >>> copied with a double fork(). Here is an example program[1] to >>> illustrate. They do get copied on FreeBSD-4.10 and Linux. I just do >>> not know if they are supposed to be copied. >> >> I test your sample >> >> it's working on Linux and FreeBSD 4.0 but failing on FreeBDS 5.2 et >> 5.3. the process stays blocked on the suspend call >> >> I rewrite another sample with the same model, joined here, as we wrote >> it in our main program. It's working also on Linux but failing on all >> FreeBSD included FreeBSD 4.0, 5.2 et 5.3 >> >> ... >> >> the wait call return with an errno ECHILD ?? > > The children are exiting before the parents (due to sleep()'s) get to > their wait()'s. > >> did you have any idea if the problem will be solve by the FreeBSD team >> or not ? > > I updated my bug report and tried to notify David Xu but the e-mail > server rejected the e-mail (too many "Received" headers). I am also > Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in > February.
Now that I've had time to look at it, both problems appear to be related to signals, but that's about as far as it goes. I wouldn't expect any connection unless it's a general signal race condition. Greg -- See complete headers for address and phone numbers.
pgpzBmvixO1u4.pgp
Description: PGP signature
