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 >
