Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Denys Vlasenko <dvlasenk@redhat.com>
Newsgroups: gnu.bash.bug
Subject: Re: "wait" loses signals
Date: Mon, 24 Feb 2020 11:50:55 +0100
Lines: 37
Approved: bug-bash@gnu.org
Message-ID: <mailman.1488.1582541468.2412.bug-bash@gnu.org>
References: <dab35be8-4b56-5887-bfa4-37ea7383864a@case.edu> <750d460d-b8a4-4157-1488-9f4d9f973715@redhat.com> <35034c85-fd5a-5034-a2d5-e3903888069d@case.edu> <cf7adbec-e705-1071-34e1-50f8188f0edc@redhat.com> <d60f1dbc-990d-7291-e075-b67c07f61a86@case.edu> <00620c20-19ea-e71e-dc1b-926847901f82@redhat.com> <25750.1582534783@jinx.noi.kre.to> <47762f41-e393-30cd-50ed-43c6bdd29856@redhat.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: bug-bash@gnu.org, Harald van Dijk <harald@gigawatt.nl>
To: Robert Elz <kre@munnari.OZ.AU>, chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
In-Reply-To: <25750.1582534783@jinx.noi.kre.to>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15956

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).