Q: ->attaching && REPORT_CALLBACKS()

[Oleg Nesterov]

On 03/11, Roland McGrath wrote:
>
> > 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.
>
> That is indeed what happens in that case.  But that one is not a
> specific "should not", it's just what happens to be true given what we
> say about the "asynchronous" attach case in general.  That is, that an
> "asynchronous" attach + set_events makes no guarantees about how
> instantly you start to get event reports.

Yes, yes, I understand. In short: I greatly misinterpreted the comment.

> > 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.
>
> As you can see in the cited thread, that's what I thought too.  Jim
> convinced me that the (new) current behavior is more useful.
> ...
> Jim's use seems fairly representative of situations where this might
> come up.  He's concerned with the EXEC event as the "old address space
> is gone, new one is here" event.  It's also the "my name changed"
> event that may be triggering a new tracing setup.

Aha, thanks!

> > 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.
>
> It would be "safe", meaning it doesn't have race problems like the
> target != current case does for touching ->attached here.

Yes, I see. Again, I confused "safe" with "not what the user wants".

> > 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.
>
> As far as the API guarantees are concerned, there is no "completes".
> When you call utrace_set_events, it becomes possible your callbacks
> get made.

Yes sure.

Thanks!

Oleg.