Re: winch trap delayed until keypress

[Linda Walsh]

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