> This was copy-and-pasted from the old code. Shouldn't we rely use > UTRACE_SIGNAL_HOLD instead ?
Perhaps so, but I'd rather leave it alone for now. The send_sig_info path has various other checks that could be relevant to the kludgey old ptrace semantics for this arcane case. Fresh prepare_signal() work happens (e.g. clearing pending blocked stop signals on SIGCONT or vice versa), the queue rlimit checks are enforced, etc. All that is implied by the legacy ptrace behavior even though surely its users haven't thought about those issues. UTRACE_SIGNAL_HOLD is really intended as "pretend I didn't dequeue it after all", with much simpler internal semantics. Thanks, Roland
