|
From: | Paul Eggert |
Subject: | Re: SIGIO and the NS port |
Date: | Sun, 21 May 2017 00:46:53 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
Alan Third wrote:
I’ve stopped the signal handler from responding to SIGIO,
I'm not following, as sigaction (SIGIO, ...) is still being called, so the signal handler deliver_input_available_signal is still responding to SIGIO, and is setting pending_signals to true.
The changes you made affect SIGUSR1 and SIGUSR2 handling, since they patch handle_user_signal: they cause the SIGUSR1 and SIGUSR2 handler to not process SIGIO events. Also, they prevent SIGIO from being masked out during non-SIGIO signal handlers. Is that what you intended? I'm not getting the connection between these non-SIGIO handlers and interrupt_input.
and the two places where the NS GUI used to raise SIGIO have been replaced with direct calls to the SIGIO handler code.
That sounds like a reasonable thing to do in any event. I don't see why the code needs to do a raise (SIGIO) when it can do a handle_input_available_signal (SIGIO);
[Prev in Thread] | Current Thread | [Next in Thread] |