[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGIO and the NS port
From: |
Alan Third |
Subject: |
Re: SIGIO and the NS port |
Date: |
Sun, 21 May 2017 13:11:40 +0100 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
On Sun, May 21, 2017 at 12:46:53AM -0700, Paul Eggert wrote:
> 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.
I’ve probably misunderstood what the code was doing. Would it be best
to just leave the signal handlers as‐is, but replace the calls to
raise(SIGIO) with direct calls as below?
> > 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);
Thanks!
--
Alan Third