> 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.
I'm very glad to do it! It was a bit of a brain dump, just hoping to get
everything on the table and have a real discussion begin. (It would be
great if someone wrote up or editted expanded explanations on the wiki.)
> > 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?"
(I won't try to explain my grammar, just my meaning. :-) I was citing the
distinction between the two kinds of places report_quiesce is now called.
The latter category includes places like syscall tracing. Here
report_quiesce does not mean that the very next thing the thread will do is
return to user mode. In fact, if UTRACE_EVENT(QUIESCE) remains set, there
will always be another callback (of the former category) before it gets to
user mode. However ("though"), said second callback ("then") may not occur
very quickly, since the thread (e.g. performing some syscall) may do active
work or uninterruptible kinds of blocking beforehand.
> > 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?"
I mean when there is nothing left to do but return to user mode. The place
this happens is utrace_get_signal, called from get_signal_to_deliver.
What's going on there is dequeuing all pending signals and acting on them,
and then returning to user mode. i.e., it's a loop, and the final
iteration is the one that decides there are no pending signals to dequeue.
(If a signal is fatal, the thread dies in the middle of one of those
iterations and never hits the natural end condition of the loop.
If a signal causes job control stop, the thread stops in the middle of one
of those iterations and then picks up in the loop again after SIGCONT.)
Currently report_signal gets called for each iteration but the last. The
idea above is that it (now called report_resume) would be called for each
iteration, including the last.
> 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?
Yes. When I said "rename report_signal to report_resume", I meant it
literally and precisely--change the name, not the signature. The
difference in its calling convention would be that the "action" argument
might initially be UTRACE_ACTION_RESUME, saying that there is no pending
signal at all. As with report_signal now, a callback could return
UTRACE_SIGNAL_* to say what should happen instead. In the
no-pending-signal case, it would have to fill in info->si_signo to be
nonzero and set return_ka if it didn't want SIG_DFL, since there will have
been no original signal number there to start with. (That's the use that
would replace utrace_inject_signal.)
> > 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?
Yes, as described above.
Thanks,
Roland
