From: David Kastrup <dak@gnu.org>
To: storm@cua.dk (Kim F. Storm)
Cc: Andreas Schwab <schwab@suse.de>, Sam Steingold <sds@gnu.org>,
emacs-devel@gnu.org
Subject: Re: busyloop in sigchld_handler
Date: Wed, 14 Mar 2007 11:00:57 +0100 [thread overview]
Message-ID: <86odmww3dy.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <m3k5xknpoq.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Wed\, 14 Mar 2007 10\:24\:05 +0100")
storm@cua.dk (Kim F. Storm) writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> The CPU is claimed by the process with the loop, so no other process
>>>> may actually progress to a state which can be "wait"ed for.
>>>
>>> Of there is no child to be waited for then there is no loop.
>>
>> In order to make sophistics solve the problem, you need to convince
>> the kernel.
>
> This happens in the sigchld handler - which is only invoked when there
> is a dead child (zombie) to "wait3" for - so we should not have to wait
> for the dead child to "really die".
>
> In addition, we call wait3 with WNOHANG, so it is not supposed to block
> if there are no dead childs.
>
> That why Andreas and I can't really see where the busy loop can
> happen, but since the loop _is_ observed, it is important to
> understand why it happens, not just install a "semi-random" patch
> which fixes the problem, but nobody can explain why.
>
> Perhaps we need to ask a Linux kernel hacker?
>
> Here's the code in condensed form:
>
> while (1)
> {
> while (1)
> {
> errno = 0;
> pid = wait3 (&w, WNOHANG | WUNTRACED, 0);
> if (! (pid < 0 && errno == EINTR))
> break;
> /* Avoid a busyloop: wait3 is a system call, so we do not want
> to prevent the kernel from actually sending SIGCHLD to emacs
> by asking for it all the time. */
> sleep (1);
> }
>
> if (pid <= 0)
> return;
> /* handle death of child `pid' */
> }
>
>
> So the problem is the interpretation of an EINTR error from
> wait3(..., WNOHANG, ...).
>
> The Linux man page says:
>
> EINTR if WNOHANG was not set and an unblocked signal or a SIGCHLD was
> caught.
>
> So WNOHANG => EINTR is not explained, but the usual meaning is that
> the wait3 was interrupted by some other signal - and if there is a
> loop, that signal is repeated somehow ...
>
> However, with the test code I inserted into the sigchld handler, and
> then executing M-x complile once after starting emacs -Q, it clearly
> shows that:
>
> a) the sigchld handler is entered exactly once.
>
> b) the first wait3 returns immediately with the pid
> of the compile process,
>
> c) the next wait3 returns immediately with 0, since
> there are no more processes to wait for.
>
> So where's the busy loop?
>
> The above code is the version for Linux - other variations of the code
> are used for other platform, but the OP said this was observed on a
> GNU/Linux system.
The signal manpage says:
When a signal occurs, and func points to a function, it is
implementation-defined whether the equivalent of a:
signal(sig, SIG_DFL);
is executed or the implementation prevents some
implementation-defined set of signals (at least including
sig) from occurring until the current signal handling has
completed.
So even though SIGCHLD may be interrupted by another signal, this does
not mean that the other signal handler gets a chance to run.
Maybe we should not loop, but instead rather return in the signal
handler, possibly reraising the signal? That may give the system the
leeway to deal with whatever caused EINTR in the first place.
--
David Kastrup
next prev parent reply other threads:[~2007-03-14 10:00 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-11 18:33 busyloop in sigchld_handler Sam Steingold
2007-03-11 19:39 ` Kim F. Storm
2007-03-11 19:43 ` David Kastrup
2007-03-11 19:51 ` Sam Steingold
2007-03-11 20:42 ` Kim F. Storm
2007-03-11 21:06 ` Sam Steingold
2007-03-11 21:14 ` Eli Zaretskii
2007-03-11 21:17 ` Sam Steingold
2007-03-11 21:51 ` Eli Zaretskii
2007-03-11 22:21 ` Sam Steingold
2007-03-12 4:24 ` Richard Stallman
2007-03-12 7:00 ` David Kastrup
2007-03-13 2:43 ` Richard Stallman
2007-03-11 22:27 ` Andreas Schwab
2007-03-11 22:30 ` Kim F. Storm
2007-03-12 17:37 ` Andreas Schwab
2007-03-12 17:53 ` Sam Steingold
2007-03-12 18:45 ` Andreas Schwab
2007-03-12 18:57 ` Sam Steingold
2007-03-12 19:28 ` Andreas Schwab
2007-03-12 19:34 ` David Kastrup
2007-03-12 21:36 ` Andreas Schwab
2007-03-13 7:29 ` David Kastrup
2007-03-13 9:29 ` Andreas Schwab
2007-03-13 22:19 ` David Kastrup
2007-03-13 22:28 ` Andreas Schwab
2007-03-13 22:54 ` David Kastrup
2007-03-13 23:17 ` Andreas Schwab
2007-03-14 7:06 ` David Kastrup
2007-03-14 9:24 ` Kim F. Storm
2007-03-14 10:00 ` David Kastrup [this message]
2007-03-14 10:22 ` Andreas Schwab
2007-03-14 10:52 ` David Kastrup
2007-03-14 11:01 ` Andreas Schwab
2007-03-14 11:12 ` David Kastrup
2007-03-14 12:29 ` Andreas Schwab
2007-03-14 10:01 ` Andreas Schwab
2007-03-14 13:15 ` Kim F. Storm
2007-03-14 13:41 ` Andreas Schwab
2007-03-14 14:10 ` Kim F. Storm
2007-03-14 14:12 ` Andreas Schwab
2007-03-14 15:02 ` Kim F. Storm
2007-03-14 16:34 ` Andreas Schwab
2007-03-16 9:34 ` Kim F. Storm
2007-03-16 9:59 ` Andreas Schwab
2007-03-14 3:24 ` Richard Stallman
2007-03-14 17:34 ` David Kastrup
2007-03-26 1:47 ` YAMAMOTO Mitsuharu
2007-03-26 2:02 ` Sam Steingold
2007-03-26 2:17 ` YAMAMOTO Mitsuharu
2007-03-28 10:02 ` Kim F. Storm
2007-03-28 15:19 ` Chong Yidong
2007-03-28 15:25 ` Andreas Schwab
2007-03-28 15:33 ` Kim F. Storm
2007-03-28 15:37 ` Andreas Schwab
2007-03-28 20:18 ` Kim F. Storm
2007-03-29 17:59 ` Richard Stallman
2007-03-28 15:30 ` Alfred M. Szmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86odmww3dy.fsf@lola.quinscape.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=schwab@suse.de \
--cc=sds@gnu.org \
--cc=storm@cua.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).