From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Schwab Newsgroups: gmane.emacs.devel Subject: Re: busyloop in sigchld_handler Date: Tue, 13 Mar 2007 10:29:41 +0100 Message-ID: References: <45F59395.4010708@gnu.org> <45F5A2B4.7090301@gnu.org> <85ejnumf1o.fsf@lola.goethe.zz> <868xe11tzu.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1173778213 6949 80.91.229.12 (13 Mar 2007 09:30:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Mar 2007 09:30:13 +0000 (UTC) Cc: Sam Steingold , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 13 10:30:07 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HR3KY-0004wd-9p for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 10:30:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HR3LJ-0003F9-5L for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 04:30:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HR3L6-0003DH-Uu for emacs-devel@gnu.org; Tue, 13 Mar 2007 05:30:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HR3L5-0003CV-G1 for emacs-devel@gnu.org; Tue, 13 Mar 2007 05:30:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HR3L5-0003CS-AK for emacs-devel@gnu.org; Tue, 13 Mar 2007 04:30:39 -0500 Original-Received: from mx2.suse.de ([195.135.220.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HR3KB-0002jG-UC; Tue, 13 Mar 2007 05:29:44 -0400 Original-Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 765E2215C2; Tue, 13 Mar 2007 10:29:41 +0100 (CET) X-Yow: I'm mentally OVERDRAWN! What's that SIGNPOST up ahead? Where's ROD STERLING when you really need him? In-Reply-To: <868xe11tzu.fsf@lola.quinscape.zz> (David Kastrup's message of "Tue, 13 Mar 2007 08:29:41 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67849 Archived-At: David Kastrup writes: > Andreas Schwab writes: > >> David Kastrup writes: >> >>> Andreas Schwab writes: >>> >>>> If you don't use WNOHANG you open up a race where several processes = may >>>> have their status changed, but only one signal is sent (non-realtime >>>> signals are not queued). >>> >>> How does WNOHANG protect against that? >> >> It makes it possible to loop around without blocking. > > Too bad you snipped the details of my question. It does not make it > possible to loop around without preemption. What do you mean with "without preemption"? > In fact, it _forces_ preemption at some point of time (this is the only > way to exit the infinite loop on a single-processor system), Which inifinite loop? > and when preemption happens, of course several signals may be delivered > together: after all, a preempted process is not so likely to get > scheduled right again. I don't understand how preemption comes into play here. >> On system without WNOHANG there needs to be other mechanisms to >> garantee one signal per child (they probably redeliver the signal as >> long as such children exist). > > Again: I don't see that this guaranteed one signal per child, and you > did not explain how it could. >>From POSIX: If _POSIX_REALTIME_SIGNALS is defined, and the implementation queues the SIGCHLD signal, then if wait( ) or waitpid ( ) returns because the statu= s of a child process is available, any pending SIGCHLD signal associated with the process ID of the child process shall be discarded. Any other pending SIGCHLD signals shall remain pending. Otherwise, if SIGCHLD is blocked, if wait( ) or waitpid ( ) return because the status of a child process is available, any pending SIGCHLD signal shall be cleared unless the status of another child process is available. Andreas. --=20 Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED= 5 "And now for something completely different."