> 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