|
From: | Harald van Dijk |
Subject: | Re: "wait" loses signals |
Date: | Wed, 19 Feb 2020 23:53:56 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Thunderbird/73.0 |
On 19/02/2020 20:30, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:A bug report from Harald van Dijk: test2.sh: trap 'kill $!; exit' TERM { kill $$; exec sleep 9; } & wait $! The above script ought exit quickly, and not leave a stray "sleep" child: (1) if "kill $$" signal is delivered before "wait", then TERM trap will kill the child, and exit.This strikes me as a shaky assumption, dependent on when the shell receives the SIGTERM and when it runs traps. (There's nothing in POSIX that says when pending traps are processed. Bash runs them after commands.)
The bash documentation says traps will not be executed until the command completes if it receives a signal while waiting for the command to complete, but it does not say the same for when it receives a signal before waiting for a command to complete. This may be an oversight in the documentation.
POSIX says in the description of the trap command "Otherwise, the argument action shall be read and executed by the shell when one of the corresponding conditions arises." Because it says "when", not "after", if interpreted literally, it does not even allow waiting until the current command finishes executing. I realise that that is definitely not the way it is meant to be interpreted, but I am not sure what is. I consider the assumption that the test script is supposed to work a reasonable one, but it is possible that this is considered strictly a QoI issue.
But to be clear, regardless of what POSIX requires, I was less concerned with prodding other shell authors into changing their shells and more with seeing what I can do in my shell. I want to have a shell that is capable of handling scripts like this, but it is fine with me if other shells do not share that as a goal.
Thanks for looking into this despite your scepticism on the validity of the test. Your description of what happens in bash when this ends up sleeping probably applies to all shells that behave the same way.
Cheers, Harald van Dijk
[Prev in Thread] | Current Thread | [Next in Thread] |