[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change in process.c

From: Jan Djärv
Subject: Re: Change in process.c
Date: Wed, 28 Mar 2007 21:08:13 +0200
User-agent: Thunderbird (X11/20070302)

Sam Steingold skrev:
Andreas Schwab wrote:
Sam Steingold <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]