[Top][All Lists]

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

Re: busyloop in sigchld_handler

From: Sam Steingold
Subject: Re: busyloop in sigchld_handler
Date: Mon, 12 Mar 2007 14:57:56 -0400
User-agent: Thunderbird (X11/20061107)

Andreas Schwab wrote:
Sam Steingold <address@hidden> writes:

Andreas Schwab wrote:
Sam Steingold <address@hidden> writes:

wait3 is a system call, which, when invoked in a loop, prevents the
kernel from doing anything else (in this case, sending SIGCHLD to
emacs). sleep allows the kernel some time to pass the signal.
I don't find this explanation convincing at all.  Since the system call is
made _inside_ the signal handler, the signal is actually blocked here, so
it cannot be delivered anyway.
yes, you are right.
what I should have said was that by making a system call in a busyloop,
emacs prevents the kernel from doing what it needs to do to the the child
so that wait3 will succeed.

What does the kernel have to do?  The EINTR error will only happen when
the system call was interrupted _and_ a signal handler was called.

I don't know the details, but the kernel obviously has to do SOMETHING when the child process terminates: it has to notice the state change so that wait3 in emacs will return "yes, the child is dead" instead of "nothing for you yet". The busyloop prevents the kernel from doing anything for some time.

Now, it might be better to remove the WNOHANG option instead (except that signal handlers are not supposed to hang), or use usleep(10000) instead of sleep(1), but the busyloop is what has to be fixed.

Please also note that I am not in any way an expert in kernel matters.


reply via email to

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