Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Patrick Palka <patrick@parcs.ath.cx>
To: gdb-patches@sourceware.org
Cc: Patrick Palka <patrick@parcs.ath.cx>
Subject: [PATCH] Explicitly call rl_resize_terminal() in TUI's SIGWINCH handler
Date: Wed, 22 Apr 2015 23:49:00 -0000	[thread overview]
Message-ID: <1429746560-16979-1-git-send-email-patrick@parcs.ath.cx> (raw)

(I am looking into syncing our copy of readline to the latest version,
6.3.)

In readline 6.3, the semantics of SIGWINCH handling has changed.
When a SIGWINCH signal is raised, readline's rl_sigwinch_handler() now
does not immediately call rl_resize_terminal().  Instead it sets a flag
that is checked by RL_CHECK_SIGNALS() at a point where readline has
control, and calls rl_resize_terminal() if said flag is set.

This change is item (c) in https://cnswww.cns.cwru.edu/php/chet/readline/CHANGES

  c.  Fixed a bug that caused readline to try and run code to modify its idea
      of the screen size in a signal handler context upon receiving a SIGWINCH.

This change in behavior is important to us because TUI's
tui_sigwinch_handler() relies on the assumption that by the time it's
called, readline will have updated its knowledge of the terminal
dimensions via rl_resize_terminal().  Since this assumption no longer
holds true, TUI's SIGWINCH handling does not work correctly with
readline 6.3.

To fix this issue this patch makes TUI explicitly call
rl_resize_terminal() in tui_async_resize_screen() at the point where
current terminal dimensions are needed.  (We could call it in
tui_sigwinch_handler too, but since readline avoids doing it, we are
probably safer off avoiding to call it in signal handler context as
well.)  After this change, SIGWINCH handling continues to work properly
with both readline 6.2 and 6.3.

Since we no longer need it, we could now explicitly disable readline's
SIGWINCH handler by setting rl_handle_sigwinch to zero early on in the
program startup but I can't seem to find a good spot to place this
assignment (the first call to rl_initialize() occurs in
tui_initialize_readline() so the assignment should occur before then),
and the handler is harmless anyway.
---
 gdb/tui/tui-win.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gdb/tui/tui-win.c b/gdb/tui/tui-win.c
index 77218e8..3cf38fc 100644
--- a/gdb/tui/tui-win.c
+++ b/gdb/tui/tui-win.c
@@ -848,6 +848,7 @@ tui_async_resize_screen (gdb_client_data arg)
   if (!tui_active)
     return;
 
+  rl_resize_terminal ();
   tui_resize_all ();
   tui_refresh_all_win ();
   tui_update_gdb_sizes ();
-- 
2.4.0.rc2.31.g7c597ef


             reply	other threads:[~2015-04-22 23:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 23:49 Patrick Palka [this message]
2015-04-23 11:07 ` Pedro Alves
2015-04-23 11:51   ` Patrick Palka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1429746560-16979-1-git-send-email-patrick@parcs.ath.cx \
    --to=patrick@parcs.ath.cx \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox