Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: "wait" loses signals
Date: Mon, 24 Feb 2020 11:18:11 -0500
Lines: 42
Approved: bug-bash@gnu.org
Message-ID: <mailman.1499.1582561108.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> <96ce0406-36fd-f93e-6ebc-49bd58b52148@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu, Denys Vlasenko <dvlasenk@redhat.com>, bug-bash@gnu.org, Harald van Dijk <harald@gigawatt.nl>, Daniel Colascione <dancol@google.com>
To: Robert Elz <kre@munnari.OZ.AU>
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQgQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT6IYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxa5AQ0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmYhJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ==
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <25750.1582534783@jinx.noi.kre.to>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15961

On 2/24/20 3:59 AM, Robert Elz wrote:

> The relevance of this is that if a signal arrives while the wait command
> is executing (or as Chet suggested, while doing whatever housekeeping is
> needed to prepare to run it, like looking to see what command comes next)
> but before the relevant wait*() system call is running, the trap won't
> be run until after the wait command completes.

There are two separate cases here: if the signal arrives before the wait
command has begun executing (during `housekeeping') or if it arrives
after the wait command has begun running but before it calls whatever
system call it uses to wait for children.

The second case is relatively easy to solve; Jilles wrote a message
detailing the alternatives. Bash uses the longjmp-out-of-the-trap-signal-
handler mechanism. The trap handler only has to know that the wait builtin
is running and that there's a valid saved environment to longjmp to.

The first case is trickier: there's always going to be a window between
the time the shell checks for pending traps and the time the wait builtin
starts to run. You can't really close it unless you're willing to run the
trap out of the signal handler, which everyone agrees is a bad idea, but
you can squeeze it down to practially nothing.

I think I've got a way to close that and make signals that arrive in that
first case act as if they arrived `while the shell is waiting by means of
the wait utility'. It's not much code and not disruptive.

With that, bash runs the original test script (100,000 iterations) on RHEL7
and macOS without a `stray' sleep. It's in the git devel branch.

I'm going to defer the question of whether or not that's the `right' thing
to do -- people have been trying to make signals into an IPC mechanism
since Berkeley introduced `reliable signals'.

Can we all take a breath now?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/