[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: winch trap delayed until keypress

From: Egmont Koblinger
Subject: Re: winch trap delayed until keypress
Date: Fri, 23 May 2014 02:58:14 +0200


Disclamer: this might be Linux specific, I don't know too much about
other Unixes.

SIGWINCH *does* interrupt system calls (easily causing a whole lot of
headache for many people), unless the signal is blocked or ignored (as
it is by default).  And there's a cool pselect() syscall.  Combining
these two, one can easily handle window change only when the prompt is
displayed, without race condition, and without running heavy stuff in
the handler -- this is exactly why pselect was invented, according to
my best knowledge.

The signal should be blocked by default.  That is, you don't have to
worry about syscalls being interrupted by sigwinch anywhere in bash,
except for one designated place.  When bash starts waiting for the
next user keypress, instead of a read() it should issue a pselect()
which atomically unblocks the signal and starts waiting for input.  If
the window size changes (or if a previously blocked signal is
delivered right away), the pselect call is interrupted and signal is
atomically blocked again, the signal handler is run which can set a
flag (or it doesn't even need to do anything, bash could query the
terminal size and compare with the previous value).  Right after the
pselect, you can safely see whether there was a window size change and
take proper action, outside of signal handler.

Are there any platforms where this can't be done?


On Thu, May 22, 2014 at 10:47 PM, Linda Walsh <address@hidden> wrote:
> Chet Ramey wrote:
>> On 5/22/14, 1:16 AM, Linda Walsh wrote:
>> Further complicating things is the fact that there is not any portable
>> way to specify that SIGWINCH should interrupt system calls.  There is
>> the SA_RESTART flag that says *not* to fail with EINTR, but there is no
>> portable flag that has the opposite effect.  (You don't want SIGWINCH to
>> interrupt system calls anyway; it's supposed to be transparent.)
>>> But it sounds like my winch handler that would tell me the size of
>>> a resized screen will now be broken.
>> I told you it would need to be changed almost a year ago:
>> http://lists.gnu.org/archive/html/bug-bash/2013-06/msg00119.html
> ----
> How would you suggest changing it so that it continues to work?
> I.e. if bash traps the signal but doesn't propagate it, it seems
> bash is "sitting on" the needed data.
> Effectively, readline is going off to sleep and not responding to
> external events coming from a windowing system.  Even if I have a
> timer-interrupt or wakeup call, that woke up every 1/2 or 1/10th
> second, it wouldn't able to see if WINCH happened because
> readline would have caught the interrupt and set it's flag but won't
> deliver it to a script-signal handler until some keypress:
> is that right?
> Or would a script even be able to be woken up on a timer interrupt?
> i.e. if you don't deliver signals until a user keypress, how would
> an alarm/timeout handler be called?
> If they are called, how are they different from WINCH?
> FWIW, I had to solve a similar problem in perl.  In it, I wanted
> to wait in a select type call for input, timeout or SIGWINCH.
> If the call was interrupted (due to WINCH), I'd still set the flag
> in my code to be processed on the next wakeup.  Problem was, the next
> wakeup never came.  The call reliably did not restart the timed wait
> but would never return until the next keypress.
> I worked around the problem by splitting the keyboard reader off into
> a separate execution thread where it could block all signals and thus
> not be affected.  It would return results via a pipe to the parent --
> who handled the signals by setting a flag in the "bottom-half" (the
> interrupt (signal) handler), and then doing needed processing in
> the 'top-half' -- mainline of program execution -- as it fell out
> of the "select" call due to being interrupted.
> The parent could get input from the 'input-gathering-only' sub-proc
> via a handle in the select.  So that gave instant input handling
> as well as instant signal handling -- both in the "top-half"
> of the application (top-half meaning not the interrupt driven part
> of the code).
> It seems like bash would have to do something similar to avoid
> problems.
> Perhaps that's the solution that is needed to avoid the race
> problems 4.2 was having?
> If bash doesn't do it, how can a script get the notification?
> in was prematurely interrupted -- but the response would be in the
> "top-half"
> (in driver-speak), in the bottom half, only a flag was set.
> process and

reply via email to

[Prev in Thread] Current Thread [Next in Thread]