On 15 July 2013 15:35, Chet Ramey <chet.ra...@case.edu> wrote:
> On 7/14/13 2:38 PM, Cedric Blancher wrote:
>> The tests below is from the ongoing work of David Korn and Roland
>> Mainz to make signals in ksh93 reliable and predictable (so far no
>> shell tested really does it). I derived one of their tests and found
>> that bash doesn't handle realtime signals properly either:
>> bash -c '{ trap ":" RTMIN ; kill -STOP ${BASHPID} ; true ; } & ((
>> pid=$! )) ; sleep 5 ; maxi=$(ulimit -i) ; for ((i=0 ; i < (maxi*2) ;
>> i++)) ; do kill -RTMIN $pid ; done ; kill -CONT $pid ; wait ; true'
>> This prints 1, but IMO should print $(ulimit -i) as integer value and
>> then lots of errors from kill(1) because no further signals can be
>> queued to $pid because ulimit -i is exceeded for that child process.
>
> Two things: First, the script as supplied doesn't print anything.Any idea why there is this difference? > Second, > the kill system call never returns < 0, so the kill builtin won't print > an error message. > > I took your script, added a little debugging code to bash, and ran it. > It sent 63000+ signals to the stopped process without kill(2) ever > returning an error. Either your ulimit -i is greater than 63000 or we have a Linux bug. If ulimit -i is reached then kill(1) should fail. Lionel
