It probably depends on the window manager: some have you drag an outline (or static snapshot) of the window, some do "live" resizing (and some can be configured either way). For me the most common way I resize a terminal is by maximising or unmaximising a GNOME Terminal, which thankfully only seems to trigger one SIGWINCH per (un)maximise.
There can be other ways to trigger a resize too, like opening a second tab in a maximised GNOME Terminal window: the creation of the tab widget consumes some screen real estate, so that's a terminal resize too. Opening a second tab and (un)maximising are relatively frequent operations for me.
I'm sure there are many real-world cases this workaround can't fix, sadly. But I can say that it definitely improved behaviour for me in some real-world cases, e.g. a 'bzr pull' over plain HTTP.
It probably depends on the window manager: some have you drag an outline (or static snapshot) of the window, some do "live" resizing (and some can be configured either way). For me the most common way I resize a terminal is by maximising or unmaximising a GNOME Terminal, which thankfully only seems to trigger one SIGWINCH per (un)maximise.
There can be other ways to trigger a resize too, like opening a second tab in a maximised GNOME Terminal window: the creation of the tab widget consumes some screen real estate, so that's a terminal resize too. Opening a second tab and (un)maximising are relatively frequent operations for me.
I'm sure there are many real-world cases this workaround can't fix, sadly. But I can say that it definitely improved behaviour for me in some real-world cases, e.g. a 'bzr pull' over plain HTTP.