|
From: | Sam Steingold |
Subject: | Re: busyloop in sigchld_handler |
Date: | Mon, 12 Mar 2007 14:57:56 -0400 |
User-agent: | Thunderbird 1.5.0.8 (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. Sam.
[Prev in Thread] | Current Thread | [Next in Thread] |