Should SIGNAL_REPORT take preference to queued signal?

[Roland McGrath]

> However I was looking if there were reasons why "interrupt" from a
> tracing thread would be preferred over a "queued signal"?

This is the fundamental point of requesting utrace reports (either
UTRACE_REPORT or UTRACE_INTERRUPT)--the tracer gets control before any
user-visible action can happen.  Dequeuing a signal is a user-visible
action.

The problem you are having is that the signal you're concerned with is not
a "real" signal.  It's one that you have instigated.  This is a well-known
issue.  In fact, it's one of the motivating issues for utrace, but it's
always been a "fix this later on" plan.

You can see the same issue with ptrace today.  For example, if a debugger
is using single-step and then exits suddenly, there can be a pending
SIGTRAP left from the single-step, that then gets delivered to the process
after the debugger is no longer there to intercept it.

The eternal to-do list item for this is "utrace extension events".  In
short, to stop overloading signals for these debugger purposes and use a
dedicated utrace notification mechanism instead.  I've long had a few ideas
about the details of this, but it all remains to be fleshed out.  I don't
think we want to try to get into that until after the basic utrace code
gets merged upstream.


Thanks,
Roland