Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15956

Re: "wait" loses signals

Show key headers only | View raw

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).

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: "wait" loses signals Denys Vlasenko <dvlasenk@redhat.com> - 2020-02-24 11:50 +0100

csiph-web