On Fri, Jul 5, 2013 at 8:07 PM, Irek Szczesniak <[email protected]> wrote: > On Mon, Jul 1, 2013 at 9:53 AM, Irek Szczesniak <[email protected]> wrote: >> On Mon, Jul 1, 2013 at 2:43 AM, Roland Mainz <[email protected]> >> wrote: >>> Erm... why does ksh93's kill(1) implementation always send SIGCONT >>> after sending the requested signal ? >>> >>> The following code... >>> -- snip -- >>> 1210 if(pid>=0) >>> 1211 { >>> 1212 if(qflag) >>> 1213 { >>> 1214 if(pid==0) >>> 1215 goto no_sigqueue; >>> 1216 r = >>> sigqueue(pid,sig,sig_val); >>> 1217 } >>> 1218 else >>> 1219 r = kill(pid,sig); >>> 1220 if(r>=0 && !stopsig) >>> 1221 { >>> 1222 if(pw->p_flag&P_STOPPED) >>> 1223 pw->p_flag &= >>> ~(P_STOPPED|P_SIGNALLED); >>> 1224 if(sig) >>> 1225 kill(pid,SIGCONT); >>> 1226 } >>> 1227 } >>> -- snip -- >>> ... always sends SIGCONT when the original signal delivery was >>> successfull... but why is this neccesary ? Technically signals are >>> queued anyway if the child is stopped and maybe the user _wants_ the >>> child to continue in the stopped state. >> >> I may have been a good intention to wake the target process up to >> guarantee it consumes the signal but IMHO its still a standard >> violation. >> It clearly says "The kill utility shall send a signal to the process >> or processes specified by each pid operand.". It does not say "a >> SIGCONT signal is send with each signal to ensure the target process >> is listening". > > I tried it with bash: > strace ~/bin/ksh -c 'trap "print xCONTx" CONT ; trap ":" RTMIN ; bash > -c "kill -RTMIN $$" ; true' 2>&1 | egrep 'SIG(CONT|RT)' > rt_sigaction(SIGCONT, {0x41410c, [], SA_RESTORER|SA_SIGINFO, > 0x7f359c717450}, {SIG_DFL, [], 0}, 8) = 0 > rt_sigaction(SIGRT_2, {0x41410c, [], SA_RESTORER|SA_SIGINFO, > 0x7f359c717450}, {SIG_DFL, [], 0}, 8) = 0 > --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_USER, si_pid=20359, si_uid=1000} --- > > bash (4.2.42(1)-release) only sends SIGRTMIN in this example. > > What I do see is that bash has code to wake up a child process of the > current shell *after* kill was used. But it doesn't legalize (POSIX) > sending SIGCONT for every kill(1) use. No other shell besides ksh93 > does it. Sun patched the feature away since it broke the SUSv3 test > suite, [snip]
Erm... actually the original patch for this added a check whether kill(1)'s target process is a child of this shell (e.g. listed by $ jobs -l #) and whether it's in the stopped state. SIGCONT would only be send if both conditions are true. My proposal for ksh93 would be to do the same... but with the "twist" of adding a -j option to explicitly enable/disable the job control functionality in kill(1) ... since IMO it may be usefull (and legal) to send signals (e.g. SIGUSR1, SIGUSR2, SIGRTMIN-SIGRTMAX etc.) to stopped shell and wake it up later to process the queued signals... ... David: What do you think ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
