SIGWINCH not delivered until letting go of resize window

Consider the below program. Now grab the terminal edge and resize by one column. Using the native OS X terminal, the signal gets fired after a short delay. In iterm2, the signal does not fire until resizing one more column or letting go of of the drag. I instrumented iterm2 and verified that the ioctl does indeed get issued at the correct time, it just doesn't arrive at the child process.

Interestingly, I tried writing an external file in the signal handler, just to check whether the signal handler was executed but something (e.g. the tty lock) was blocking it, but that didn't get written out until I stopped resizing the window completely.

I do not know OS X well enough to understand what is happening while resizing, so I'm hoping you might have an idea. OS version is 10.10.4.

/* demo_SIGWINCH.c

   Demonstrate the generation of the SIGWINCH signal. A handler for SIGWINCH
   allows the program to discover terminal window size changes; when that
   signal is generated, the program displays the new terminal window size.
*/
#include <signal.h>
#include <termios.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <unistd.h>
static void
sigwinchHandler(int sig)
{
}
int
main(int argc, char *argv[])
{
    struct winsize ws;
    struct sigaction sa;

    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sa.sa_handler = sigwinchHandler;
    if (sigaction(SIGWINCH, &sa, NULL) == -1)
        _exit(2);

    for (;;) {
        pause();                        /* Wait for SIGWINCH signal */

        if (ioctl(STDIN_FILENO, TIOCGWINSZ, &ws) == -1)
            _exit(1);
        printf("Caught SIGWINCH, new window size: "
                "%d rows * %d columns\n", ws.ws_row, ws.ws_col);
    }
}

Thanks for the test code. This inspired me to dig into this problem again, since I haven't looked into it in a long time. It seems the child process does get the signal but the redraw timer doesn't run during live resizing, so you don't see its output. I have a patch that fixes this but I'm afraid of what it will break since it will have an effect on any code that does a tracking runloop, and I don't know where all of those are (any dragging-like operations could do it, but who knows when the OS chooses to do this and what effects it might have). Since it's untestable I'm inclined to postpone this til after 3.0 is out the door. Here's the patch:

diff --git a/sources/PTYSession.m b/sources/PTYSession.m
index 3062fff..46add27 100644
--- a/sources/PTYSession.m
+++ b/sources/PTYSession.m
@@ -3371,8 +3371,7 @@ static NSTimeInterval kMinimumPartialLineTriggerCheckInterval = 0.5;
     }
 }

-- (void)scheduleUpdateIn:(NSTimeInterval)timeout
-{
+- (void)scheduleUpdateIn:(NSTimeInterval)timeout {
     if (_exited) {
         return;
     }
@@ -3400,11 +3399,12 @@ static NSTimeInterval kMinimumPartialLineTriggerCheckInterval = 0.5;
     _timeOfLastScheduling = now;
     _lastTimeout = timeout;

-    _updateTimer = [[NSTimer scheduledTimerWithTimeInterval:MAX(0, timeout - timeSinceLastUpdate)
-                                                     target:self
-                                                   selector:@selector(updateDisplay)
-                                                   userInfo:[NSNumber numberWithFloat:(float)timeout]
-                                                    repeats:NO] retain];
+    _updateTimer = [[NSTimer timerWithTimeInterval:MAX(0, timeout - timeSinceLastUpdate)
+                                            target:self
+                                          selector:@selector(updateDisplay)
+                                          userInfo:[NSNumber numberWithFloat:(float)timeout]
+                                           repeats:NO] retain];
+    [[NSRunLoop currentRunLoop] addTimer:_updateTimer forMode:NSRunLoopCommonModes];
 }

 - (void)doAntiIdle {

Milestone changed to Future Release

Great, the patch works for me!

mentioned in issue #4017

Milestone changed to Feature Complete 3.1

As pointed out in #4017 it's not winch that's delayed, it's that iterm stops processing its input while being resized.

To test this: Start OS X's builtin Terminal.app, run 'tty' and note its output. In iTerm, execute:

trap 'stty size > /dev/tty[whatever_terminal_app_printed]' WINCH

Resize, and notice that the new size always appears immediately in Terminal.

Notice that Terminal.app does a better job than iTerm, at the beginning of a resize it keeps updating its contents, but gets worse over time during a resize. Test e.g. with

while sleep 0.1; do date; done

Expected behavior: It shouldn't matter at all that the edge is dragged, iterm should keep processing its input as it does normally.

The patch above (actually now it's just flipping an #if) makes it better: iterm processes a chunk of input after about 0.5 seconds, so the screen gets updated. However, that 0.5 seconds is still too much, and this approach doesn't fix the "while"-loop above either.

Enabled by default in commit f819ed6d.

closed