Messages in this thread | | | Date | Wed, 21 Feb 2007 09:51:51 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH] fix handling of SIGCHILD from reaped child |
| |
On Tue, 20 Feb 2007 15:10:07 -0800 (PST) Roland McGrath <roland@redhat.com> wrote:
> I'm usually the stickler for anal POSIX compliance, but this is one thing > that I did notice a while ago, realized Linux had never done it, and > decided I didn't care. > Okay, I don't think this is a big trouble.
> This is one of those parts of the standard that was originally written in a > single-threaded process frame of mind, and was never amended or clarified > later when multi-threaded semantics got well-specified in the standard. > > It's clear what the requirement is trying to achieve. It lets you have a > SIGCHLD signal handler that calls wait, and be sure its call never blocks, > as long as you block SIGCHLD while making any other wait calls. But Linux > has never done this even for single-threaded processes, so existing > application code already has to cope with the race. (Anyway, this > guarantee is not all that helpful if you have more than one child and so > might be running the handler once after SIGCHLD was generated more than > once. You can't just use WNOHANG in your handler because you aren't > actually guaranteed that the zombie is ready already when you get the SIGCHLD.) > > This guarantee is not of any use when there might be other threads with > SIGCHLD unblocked or other threads that call wait* functions (calls that > draw from the same pool of PIDs anyway). There can always be another > thread that just dequeued the SIGCHLD but hasn't gotten into its handler > yet, so clearing the pending SIGCHLD doesn't really cover it. > > Unhelpful as it is the multithreaded context, I think it's clear that the > standard's wording means "when SIGCHLD is blocked by the thread calling > wait", but in fact as to being a guarantee it's only meaningful when > SIGCHLD is blocked by all threads. The mention of blocking the signal is > only there to remind you that well-defined semantics about a "pending" > signal only ever apply when the signal is blocked. If any thread has it > unblocked, then "pending" is an ephemeral condition not necessarily > observable at all--as soon as you could say it's pending, some such thread > might be handling it. > > The "if there is another child available" test is rather ugly to do > correctly now. It would be less so if the children list moved into > signal_struct and was just shared directly. The most "correct" it can get > is still not all that useful in a multithreaded context. So I'm pretty > ambivalent about bothering with this. > Hmm, okay. It seems a good workaround to say "please use WNOHANG always in your SIGCHLD handler's wait*() call"
My only concerns is that LSB people say wait/waitpid meets SUSv3.
Thanks, -Kame
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |