On 2/24/20 9:59 AM, Robert Elz wrote:
And that is, when the wait/waitpid/wait3/wait4/waitid/wait6 (whatever the
shell uses) system call returns EINTR, the wait utility exited with a
status indicating it was interrupted by that signal (status > 128 means
128+SIGno) and runs the trap.
This is racy. Even if you try to code is as tightly as possible:
if (got_sigs) { handle signals }
got_sigs = 0;
pid = waitpid(...); /* without WNOHANG */
if (pid < 0 && errno == EINTR) { handle signals }
since signals can be delivered not only while waitpid() syscall
is in kernel, but also when we are only about to enter the kernel
- and in this case, the shell's sighandler will set the flag variable,
but then we enter the kernel *and sleep*.
Because that is what shells actually did - the alternative being to
simply restart the wait on EINTR like many other system calls that are
interrupted by signals are conventionally restarted.
Like it or not, that's what shells did, what most still do, and what
the standard says must be done.
Standard does not say that. It says "when the shell is waiting for an
asynchronous command to complete", it does not say "when the shell is
waiting in a waitpid() syscall".
Yes, you are right, you can argue that shell is minimally fulfilling
standard's requirement if it does something like my code example.
I am arguing that it can be made better: it can be coded so that
signal has no time window to arrive before waitpid() but have its
trap delayed to after "wait" builtin ends (which might be "never", mind you).
