On 07/21, Roland McGrath wrote: > > > So, if we do not want to add the special (and not-a-report) hooks > > into engine->ops, then perhaps it makes sense to do > [...] > > That is exactly the kludge
I fully agree with the "kludge" above. > > So, perhaps we can just add engine->ops->notify_stopped() (or even [...] > > My main point was that we should look for an entirely different way to > attack the problem. If I thought this hook would only be used for > ptrace, it might be fine. (OTOH then it's not all that much better than > the terrible ptrace-only kludge.) But AFAICT we'd likely wind up with > every other new utrace module that cares about doing synchronization > with debugger threads needing to use this hook too. That's why I want > to talk about the general case in the utrace API, and not just ptrace. Yes sure. That is why I tried to talk about utrace notifications "in general", not only about ptrace case. > Let's ignore SIGCHLD for a moment, and just think about ptrace's > report_* waking up wait. That is like what we expect will be the > general case of this: a debugger thread wants to sleep somehow and have > its report_* callbacks say "wake the debugger so it can examine me". > > So, how does the utrace module writer build that? You'd probably use > wait_event() et al in your debugger thread, and wake_up() in report_* > callbacks. OK. > (That's approximately what you have in ptrace+wait.) Hmm. Except in this case ptracer can be running. It is not placed on any wqh, but still needs a notification. > So how much is satisfied with a "delayed wake-up" (rather than an > open-ended hook). Let's say: > > utrace_wake_up(task, engine, wqh); // replaces wake_up(wqh); > return UTRACE_STOP; // | UTRACE_SIGNAL_IGN|UTRACE_SIGNAL_HOLD > > That would mean, approximately, as if wake_up(wqh) and then the wakee > had called utrace_barrier(task,engine), but without the sched flutter. > > Formally, I think the guarantee should be "when utrace_barrier would > return for you". Technically this means that if your callback did not > use UTRACE_STOP, it's just sometime after your callback returns. But if > you did use UTRACE_STOP, then it means after the task will definitely > stop. This looks nice, but > That's all it means today, but I think we want to strengthen that > guarantee so that when you have used UTRACE_STOP (either in a callback > already in progress when you called utrace_barrier, or in a utrace_control > call before the utrace_barrier call), utrace_barrier doesn't return until > "utrace_prepare_examine will work", i.e. actually in TASK_TRACED/STOPPED. this means the meaning of utrace_barrier() should be changed? > In ptrace, I think this alone might suffice to cover things "cleanly" in > the utrace API. (That is, clean for utrace. ;-) The ptrace layer could > use the trick of a custom wake function to implement SIGCHLD A custom wake function can only be used if the wakee has already called add_wait_queue(). Wake function belongs to wait_queue_t, not to wait_queue_head_t. But this doesn't really matter. I think that using wait_queue_func_t->func() (or whatever else we use to implement the utrace-delayed-wakeup) to do ptrace-specific hacks is not better than engine->ops->special_hook(). In essence, this looks like we add another ->ops into engine implicitly. > without > needing anything but utrace_wake_up from the utrace layer. Not sure I understand how to implement this all :( Oleg.