On Mon, 26 Aug 2019 at 22:10, Josh Kunz <j...@google.com> 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