Re: winch trap delayed until keypress

[Chet Ramey]

On 5/22/14, 1:16 AM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
>> On 5/20/14, 8:28 AM, Egmont Koblinger wrote:
>>> Hi,
>>>
>>> Execute this in an interactive bash and then resize the window:
>>> trap 'stty size' winch
>>>
>>> In bash-4.2, the trap was executed immediately upon resize.  In
>>> bash-4.3, it is delayed until the next keypress.
>>
>> http://lists.gnu.org/archive/html/bug-readline/2014-05/msg00005.html
> ---
> And if the window is just displaying something -- running a shell script,
> when will it get the resize event so it can update it's display?

This is not part of the discussion about readline, but the answer is the
same as it was before: the shell will receive the signal immediately and
run any traps after the current foreground command exits.

> I.e. a window resize can easily happen when no key press is in sight,
> Seems like deferring it and at least calling it off a timer.

Let me go through how signal handling works.  Maybe that will make the
current question clearer.

1. SIGWINCH arrives during a read(2)

2. The readline signal handler is executed and sets a flag noting that
   it received SIGWINCH.  It also calls the application's SIGWINCH handler,
   if one is installed, to allow it to do the same.

3. Since SIGWINCH is not one of those signals that interrupts system calls,
   the read(2) is restarted. When it completes -- that is, when a key is
   pressed and read returns data -- readline handles the SIGWINCH. Handling
   the signal includes updating the internal state about the screen size,
   performing any needed redisplay, and calling an application-specified
   signal hook.  In bash, that hook is what runs the traps.

The difference between bash-4.2 and bash-4.3 (and readline-6.2 and 6.3)
is that bash-4.2 did steps 2 and 3 in a signal handler context.  This has
always been unsafe, but is now causing problems with the kernel and libc.

The most you can safely do in a signal handler is to set a flag (ideally
of type sig_atomic_t).  There are functions that are `signal safe' and
that you can run in a signal handler, but they are not particularly useful
in this case.  Even a longjmp out of a signal handler is dangerous and can
lead to problems.

glibc is particularly bad -- it has all kinds of internal private state
that has to be preserved in the library itself, like locks around memory
allocation  functions, which is not signal-safe.  Bash-4.3 and readline-6.3
both go to considerable lengths to avoid running aribitrary code (e.g.,
parsing and executing traps) in a signal handler context.

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


> The whole point was to resize and it would update and tell you the size
> when you finished moving.  If you have to wait to type keys each time, that
> sorta defeats the point.
> 
> The previous version said this (checkwinsize):
>   If set, bash checks the window size after  each  command
>   and,  if necessary, updates the values of LINES and COLUMNS.
> 
> Wasn't checking the window size after each command safe?

Yes, and it still is.  This has not changed.  It isn't really germane to
this discussion.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/