Re: Racing condition leads to unstable exit code

[Reuti]

Hi,

> Am 30.09.2016 um 16:11 schrieb Luiz Angelo Daros de Luca <luizluca@gmail.com>:
> 
> Yes, this is the part that I agree. However, this is the other behavior of 
> bash wait (from bash manual)
> 
> "When Bash is waiting for an asynchronous command via the wait builtin, the 
> reception of a signal for which a trap has been set will cause the wait 
> builtin to return immediately with an exit status greater than 128, 
> immediately after which the trap is executed."
> 
> The behavior is the same for when parent or child receives the signal. When 
> it's the parent process that received it, child might still be running. It 
> simply breaks the logic of wait. In order to wait until the child exits even 
> when signal was received, I need to implement a new wait command (with some 
> hacks) like this (untested):

I don't know the process set up you want to achieve, but maybe it helps when 
you send the signal to the complete process group, and not only the parent 
process. Specifying a negative PID to `kill` will initiate this.

-- Reuti


> 
> usr1(){
>     got_signal=true
>     Do something...
> }
> 
> wait2() {
> while true; do
>     got_signal=false
>     wait $*
>     exitcode=$?
>     $got_signal || return $exitcode
> }
> 
> trap usr1 USR1
> 
> ( Child stuff... Send USR1 to parent ) &
> wait2 $!
> 
> 
> 
> Em sex, 30 de set de 2016 09:45, Chet Ramey <chet.ramey@case.edu> escreveu:
> On 9/29/16 10:58 PM, Luiz Angelo Daros de Luca wrote:
> > No problem! I already workarounded it using pipe as a semaphore. Thanks!
> >
> > It's there any chance of changing the 128+signal exit code for wait when
> > trap is received?
> > It might solve some special usecase which I'm not aware. Wait should always
> > returns exit code related to the child process, except for 127.
> 
> The shell is required to do this, and it's historical shell behavior.  If
> a process is killed by signal N, its exit status is 128+N.  That's how
> scripts know their children were killed due to a signal.
> 
> 
> > The 128+signal behavior is not even mentioned on wait documentation but on
> > signal section! If wait returns 129, I don't know wether child died because
> > of signal 1 (128+1) or if it is the current instance that received the
> > signal instead.
> 
> Posix says:
> 
> "When the shell is waiting, by means of the wait utility, for asynchronous
> commands to complete, the reception of a signal for which a trap has been
> set shall cause the wait utility to return immediately with an exit status
> >128, immediately after which the trap associated with that signal shall be
> taken."
> 
> If you want the shell to be insulated from signals that might be sent to
> its children, you either have to use job control, which works for the
> keyboard-generated signals that go to process groups, or ignore the signal
> using trap to be sure you don't receive it.
> 
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
> -- 
> Luiz Angelo Daros de Luca
> luizluca@gmail.com
>