On Fri, 16 Oct 2009 10:58:10 +0200, Oleg Nesterov wrote: > On 10/15, Roland McGrath wrote: > > > Say, ptrace(DETACH/CONT, SIGSTOP). This should work, this means > > > SIGNAL_STOP_DEQUEUED should be set even before the tracee calls > > > do_signal_stop(). But otoh it doesn't look right to set this flag > > > each time the tracee sees a stop signal from the debugger (especially > > > on detach), ->real_parent should not see multiple notifications. > > > > I don't think an extra SIGCHLD/wakeup here is going to be considered a > > problem, in the grand scheme of things. I can't really see any plausible > > way we'd (want to) preserve whether the real_parent already thought it was > > stopped or not. > > I dunno. I am not arguing, just I don't know. But, stopped-attach-transparency > seem to check this. I am not sure, but > "Excessive waiting SIGSTOP after it was already waited for\n" looks like it > it does. I'll re-check.
"stopped-attach-transparency" is there to fulfill wishes from users that 1. kill -STOP PID 2. gcore PID or gstack PID 3. kill -CONT PID should not affect PID and its interaction (such as PID parent's waitpid) in any way. But as the point 1 and 3 already signal PID's parent some SIGSTOP/SIGCONT events the parent generally does not expect it may not matter much if the point 2 does some more of such unexpected signal reporting to PID's parent. So feel free to break stopped-attach-transparency if it makes sense so. Regards, Jan
