On 7/16/13 4:31 PM, Lionel Cons wrote:
> 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?
Which command do you expect to output something?
>> 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.
ulimit -i returns 31592
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
