From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Change in process.c Date: Wed, 28 Mar 2007 21:08:13 +0200 Message-ID: <460ABD1D.6080605@swipnet.se> References: <87ejna5qwa.fsf@stupidchicken.com> <460A73BE.8020304@gnu.org> <460A8906.5080002@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1175108964 13569 80.91.229.12 (28 Mar 2007 19:09:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2007 19:09:24 +0000 (UTC) Cc: Andreas Schwab , Chong Yidong , rms@gnu.org, emacs-devel@gnu.org To: Sam Steingold Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 28 21:09:16 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 1HWdWG-0000QW-B9 for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2007 21:09:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HWdYk-0006ot-R5 for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2007 14:11:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HWdYh-0006oe-Fb for emacs-devel@gnu.org; Wed, 28 Mar 2007 15:11:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HWdYg-0006oS-Jq for emacs-devel@gnu.org; Wed, 28 Mar 2007 15:11:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HWdYg-0006oP-H0 for emacs-devel@gnu.org; Wed, 28 Mar 2007 14:11:46 -0500 Original-Received: from av9-2-sn2.hy.skanova.net ([81.228.8.180]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HWdW9-0001BN-HN; Wed, 28 Mar 2007 15:09:09 -0400 Original-Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 4E96D38B7C; Wed, 28 Mar 2007 21:09:08 +0200 (CEST) Original-Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 383C938A6D; Wed, 28 Mar 2007 21:09:08 +0200 (CEST) Original-Received: from husetbladh.homeip.net (81-235-205-78-no59.tbcn.telia.com [81.235.205.78]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id DB89B37E49; Wed, 28 Mar 2007 21:09:07 +0200 (CEST) User-Agent: Thunderbird 1.5.0.10 (X11/20070302) In-Reply-To: <460A8906.5080002@gnu.org> 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:68723 Archived-At: Sam Steingold skrev: > Andreas Schwab wrote: >> Sam Steingold writes: >> >>> there must be a sleep BEFORE the first wait. >> >> If that is the case then there is something very broken with your kernel. >> After you receive a SIGCHLD it is guarateed that what3 returns >> immediately >> with the status of the changing child. > > this is the latest fc6 kernel - I am not the only one experiencing this. I can see this too. But it is this code that gets executed over and over again (process.c, line 4810 or so): #ifdef HAVE_PTYS /* On some OSs with ptys, when the process on one end of a pty exits, the other end gets an error reading with errno = EIO instead of getting an EOF (0 bytes read). Therefore, if we get an error reading and errno = EIO, just continue, because the child process has exited and should clean itself up soon (e.g. when we get a SIGCHLD). However, it has been known to happen that the SIGCHLD got lost. So raise the signl again just in case. It can't hurt. */ else if (nread == -1 && errno == EIO) kill (getpid (), SIGCHLD); #endif /* HAVE_PTYS */ So emacs gets swamped with SIGCHILD and hogs the CPU. The (u)sleep inserted just lets the forked process get some CPU time to die properly. Now why the PTY return EIO repeatedly is another matter. Jan D.