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.
The issue came up when debugging Solaris's kernel vs. SIGRTMIN&&co.
and someone noticed that actually twice the number of signals is
generated for each kill(1) usage than expected... which quickly
becomes a serious issue if SIGQUEUE_MAX is very low.
Cedric also pointed out that it doesn't seem to be required per
http://pubs.opengroup.org/onlinepubs/009695399/utilities/kill.html and
that neither bash, dash or GNU kill behave that way...
----
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
