On 10/18, Jan Kratochvil wrote: > > 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.
Thanks a lot Jan. I'll return to this a bit later, and ask you more questions. Oleg.
