From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: busyloop in sigchld_handler Date: Tue, 13 Mar 2007 23:19:19 +0100 Message-ID: <85abyglrbs.fsf@lola.goethe.zz> 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=us-ascii X-Trace: sea.gmane.org 1173824383 31019 80.91.229.12 (13 Mar 2007 22:19:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Mar 2007 22:19:43 +0000 (UTC) Cc: Sam Steingold , emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 13 23:19:36 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 1HRFLB-0000PW-2N for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 23:19:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRFLz-0006P8-7M for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 17:20:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HRFLv-0006OT-7A for emacs-devel@gnu.org; Tue, 13 Mar 2007 18:20:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HRFLt-0006OH-QQ for emacs-devel@gnu.org; Tue, 13 Mar 2007 18:20:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRFLt-0006OE-Ja for emacs-devel@gnu.org; Tue, 13 Mar 2007 17:20:17 -0500 Original-Received: from mail-in-13.arcor-online.net ([151.189.21.53]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HRFKz-0000GP-Eh; Tue, 13 Mar 2007 18:19:21 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id EBA1C6D2C3; Tue, 13 Mar 2007 23:19:19 +0100 (CET) Original-Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id DDF1B345D5E; Tue, 13 Mar 2007 23:19:19 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-060-098.pools.arcor-ip.net [84.61.60.98]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id B478D24D48C; Tue, 13 Mar 2007 23:19:19 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 442731C4F93F; Tue, 13 Mar 2007 23:19:19 +0100 (CET) In-Reply-To: (Andreas Schwab's message of "Tue\, 13 Mar 2007 10\:29\:41 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (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:67875 Archived-At: Andreas Schwab writes: > 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"? "Preemption" means the kernel forcibly rescheduling the task. Since there is no other way in which the process will either exit the loop (since that requires some other process to change its status) or yield the CPU, it will eventually happen. >> 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? The one waiting for the demise of a process that gets no processing time for dying. >> 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. It is the only thing that can prevent a deadlock 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 status 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. I can't see how this guarantees one signal per child. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum