Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1

[Peter Maydell]

On Mon, 26 Aug 2019 at 22:10, Josh Kunz <address@hidden> wrote:
> That said, overall, fixing the SIGRTMIN+1 issue using a more-generic 
> signal-multiplexing mechanism doesn't seem *that* much better to me. It adds 
> a lot of complexity, and only saves a single signal (assuming glibc doesn't 
> add more reserved signals). The "big win" is additional emulation features, 
> like those introduced in MUX patch (being able to utilize signals outside of 
> the host range). If having those features in QEMU warrants the additional 
> complexity, then re-working this patch on-top of that infrastructure seems 
> like a good idea.

It has the huge advantage that it doesn't break existing working
binaries. That's the main reason we've never applied the 'just
swap another couple of signals' patch. The other possible
approach for avoiding binary breakage would be to silently
ignore attempts to set handlers for the signals QEMU uses,
rather than failing them. I'm not sure what fallout that
might have, though...

thanks
-- PMM