engine interaction, callback order
Jim Keniston
jkenisto at us.ibm.com
Wed Sep 5 21:50:16 UTC 2007
On Wed, 2007-08-29 at 05:15 -0700, Roland McGrath wrote:
> Renzo Davoli brought up the issue of the order of callbacks to different
> engines for the same utrace event. I know someone working on uprobes
> brought this up before (probably on the systemtap mailing list some time
> ago).
Yeah. I think one concern was that when a breakpoint is hit, a utrace
client other than uprobes might see the SIGTRAP first and take some
unwarranted action because it thinks that the task is going to die.
...
>
> These issues lead to the idea of changing how report_quiesce and
> report_signal work.
I'm having trouble connecting all the dots in the discussion below.
Maybe if you provide clarifications on the indicated points, I can give
you better feedback.
> report_signal tells you "without intervention, user
> mode will resume from right here and do this". Currently report_quiesce
> tells you that user mode might resume now if permitted, but also tells you
> at some various places just that user mode is not running right now and
> it's safe to look. (At those latter, it's not about to get back to user
> mode (or terminate) without passing through some more event points, though
> it may be working and blocking nonquiescently before then.)
I don't understand the above sentence. In particular, your use of
"though" puzzles me, and I'm not sure what you mean by "before then."
When is "then?"
> So perhaps
> rename report_signal to report_resume, and call it when dequeuing a signal
> and when dequeuing none and preparing to return to user mode after having
> stopped for QUIESCE.
What do you mean by "and when dequeuing none?"
> That is, it's called when there is the opportunity to
> decide the disposition of resuming (fatal or signal handler or normal).
> Then do away with utrace_inject_signal entirely. The EVENT(SIGNAL_*) bits
> say an engine wants report_resume for those dispositions, EVENT(QUIESCE)
> says the engine wants it no matter what.
Would there still be a report_quiesce callback? Would utrace call
report_quiesce when entering quiescence and report_resume when leaving
quiescence?
report_signal passes several signal-related args. Would those also be
passed to report_resume?
> An engine uses QUIESCE to get the
> thread to call report_resume. Then every interested engine gets the
> callback, and can see the disposition choice left by the last engine,
How? Encoded in the args to report_resume?
> and
> whether it's been left in QUIESCE.
>
> ...
>
>
> I'd appreciate any feedback anyone has in any of these areas.
>
>
> Thanks,
> Roland
>
More information about the utrace-devel
mailing list