On Fri, Jul 5, 2013 at 11:22 PM, Roland Mainz <[email protected]> wrote:
> 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 ?
Here is an (unfished) prototype patch for the issues... but the code
raises a few more questions which I'll ask in a seperate email:
-- snip --
diff -r -u build_i386_64bit_debug/src/cmd/ksh93/sh/jobs.c
build_i386_64bit_kill_sigjobcont/src/cmd/ksh93/sh/jobs.c
--- src/cmd/ksh93/sh/jobs.c 2013-06-14 22:55:44.000000000 +0200
+++ src/cmd/ksh93/sh/jobs.c 2013-07-06 00:47:08.867238765 +0200
@@ -1219,10 +1219,11 @@
r = kill(pid,sig);
if(r>=0 && !stopsig)
{
- if(pw->p_flag&P_STOPPED)
+ if(sig && pw->p_flag&P_STOPPED)
+ {
pw->p_flag &=
~(P_STOPPED|P_SIGNALLED);
- if(sig)
kill(pid,SIGCONT);
+ }
}
}
else
@@ -1231,9 +1232,15 @@
goto no_sigqueue;
if((r = killpg(-pid,sig))>=0 && !stopsig)
{
- job_unstop(job_bypid(pw->p_pid));
if(sig)
- killpg(-pid,SIGCONT);
+ {
+ /*
+ * job_unstop() will
send SIGCONT to the
+ * group if there are
stopped child
+ * processes in it
+ */
+
job_unstop(job_bypid(pw->p_pid));
+ }
}
}
}
-- snip --
----
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
