[I'm separating different issues into different reply threads.]
> 2- utrace_control(.., UTRACE_RESUME) can arrive too early, before
> ENGINE_STOP is set (in engine->flags by mark_engine_wants_stop).
I believe I already addressed this. Again, I've editted your explanation
to talk about the semantics of the API and not intermix this with utrace
internal implementation details.
> Let us name p the traced process and vm the tracer.
> t=10: p reports a system call.
> during the report function, p communicates with vm
> the report function returns UTRACE_STOP
[implementation detail removed]
> later (time t' > 10) vm calls utrace_control(p, engine, ENGINE_RESUME):
The only way your code is meaningful is if the "vm" thread of control does
something to establish its ordering with respect to the "p" thread's
actions, in particular the utrace_control() call vs the "return UTRACE_STOP".
There is a step (not shown) that is vm's action that completes its end of
"p communicates with vm". I think you mean to imply that this happens
before "p" calls utrace_control().
Do this sequence in "vm":
communicate with "p" ("p" will start towards "return UTRACE_STOP")
utrace_barrier(p, engine)
utrace_control(p, engine, UTRACE_RESUME)
The utrace_barrier() call establishes that the "p" callback, its return,
and the application of UTRACE_STOP to the engine state, are ordered before
the "vm" call to utrace_control().
"Baroque" is in the eye of the beholder.
Your API changes do not fare well in my eye.
Does this method solve your problem in practice, or not? (Use current
utrace, not past experiences which precede some relevant fixes.)
Thanks,
Roland
