> I believe the comment and "unlikely" above are not right.
>
> Neither utrace_control(STOP) nor finish_callback(action => STOP) set
> ENGINE_STOP in ->utrace_flags. They change engine->flags only, and
> ENGINE_STOP can only "migrate" to ->utrace_flags after utrace_reset().
Right. Let's take a step back, revert commit 00932db and consider the
problem case afresh. This flurry of incremental related patches just
muddles everything for me.
> This case is not unlikely, for example ENGINE_STOP is cleared after the
> previous wakeup. We are running, if ENGINE_STOP is set, UTRACE_STOP was
> used and utrace_reset() was called after that. Otherwise, _perhaps_ it
> was cleared by UTRACE_DETACH.
What we want is to change things so that this case *is* unlikely. That is,
we really want to avoid any extra O(n) work such as utrace_reset calls. It
should never be common to do one of those we don't really want to do. And,
all else being equal, when some extra O(n) work is unavoidably required,
IMHO it's better that it be in the tracer than in the tracee.
I took a different tack and committed these:
96fe3cc Revert "utrace_stop: fix UTRACE_DETACH race"
d1a14ce utrace: change UTRACE_STOP bookkeeping
64a8ca3 utrace_reset cleanup
Tell me what you think.
Thanks,
Roland
