On 03/10, Roland McGrath wrote: > > > The comment: > > > > * When target == current, it would be safe just to call > > * splice_attaching() right here. But if we're inside a > > * callback, > > > > just to clarify, "inside a callback" means inside utrace_report_xxx(), > > not only inside utrace_engine_ops->report_xxx(), right? > > Certainly what I mean when I say "a callback" is one of the functions whose > pointer lives in struct utrace_engine_ops. But I don't see how the > distinction you make could even be meaningful here.
Yes, I wasn't clear. > A utrace_attach_task() > call "inside utrace_report_foo()" could only possibly mean one made by a > ->report_foo() function utrace_report_foo() calls, since obviously there > are no hard-wired utrace_attach_task() calls in utrace.c itself. But not vise versa. I misunderstood the comment as if the new engine should not be notified if it is attached by another task while target is inside callback. I was confused by "When target == current" part of the comment, please see below. > > This is not what the user wants. > > > > It it not clear to me why the user doesn't want this. > > Jim Keniston is the user who doesn't want this. > https://www.redhat.com/archives/utrace-devel/2008-December/msg00051.html Still can't understand... If (say) ->report_exec() attaches the new engine to the same task and does utrace_set_events(EXEC), then it looks logical the new engine gets the notification too. But OK, I agree, either way is correct, and perhaps the current behaviour is more intuitive. But this means that "When target == current it would be safe just to call splice_attaching() right here" part of the comment is not right, no? Except for report_reap() target == current. > > I understand this as follows. If we add the new engine to the ->attached > > list, and if the target is inside a callback, the target can later race > > with (say) utrace_set_events(). The target can see "engine->flags & event" > > and call start_callback/finish_callback before utrace_set_events() > > completes. > > It's not a race question. There are no guarantees for such races. (That > is, utrace_set_events() calls on target!=current make no guarantee about > reporting an event that might already have started. Only if the target was > already stopped by your engine when you made the call can you be sure that > no such event can be in progress.) > > The scenario we are talking about here is fully synchronous. The target > itself is inside a callback, calling utrace_set_events() on itself. Yes, yes, I see. But I meant another case. Suppose that the debugger D attaches to T and does engine = utrace_attach_task(T, ...); utrace_set_events(T, engine, XXX); It is possible that ->report_xxx() is called before utrace_set_events() completes. But afaics currently this is not a problem. > > Another question. In any case I don't understand why do we really need > > two lists. > > [... big snip ...] Thanks for your explanations! And, in any case, > This is an optimization to consider later on Yes, yes, sure. I didn't mean we should do this change right now even _if_ it is good, and I didn't mean I think it is necessary good ;) Oleg.
