On Mon, Jul 1, 2013 at 2:43 AM, Roland Mainz <[email protected]> wrote: > Hi! > > ---- > > 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". Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
