[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [PATCH] Window resize handling

From: Mahyar Abbaspour
Subject: Re: [Nano-devel] [PATCH] Window resize handling
Date: Mon, 4 May 2015 18:19:08 +0430

On Mon, May 4, 2015 at 4:38 PM, Benno Schulenberg <address@hidden> wrote:

About the code... isn't this whole section superfluous?:

+       if (sigismember(&sigset, SIGWINCH)) {
+               /* Let pending SIGWINCH be delivered. */
+           allow_pending_sigwinch(TRUE);
+           allow_pending_sigwinch(FALSE);
+           regenerate_screen();
+           input = KEY_WINCH;
+       } else

Doesn't it get handled equally fine by what follows?

Actually no :) because there are two possible scenarios:
1- SIGWINCH is raised out of wgetch()
2- SIGWINCH is raised in wgetch() (i.e. in the blocking mode)

If the former happens and we didn't have the check for pending SIGWINCHs,
as soon as allow_pending_sigwinch(TRUE) gets executed, the pending SIGWINCH
signal would be delivered and we wouldn't ever be informed about it. So I think
the proper way is to first check for pending SIGWINCHs and if there is no pending
SIGWINCH, then we can safely go to the blocking mode. If we omit this block,
it will break this special case. However I would have no objection if you omit this block.
And the remaining allow_pending_sigwinch(FALSE);
wouldn't it be more logical to place it after
if (sigwinch_flag != sigwinch_flag_save)?

It's really a rare case but if a SIGWINCH is raised just after leaving
the blocking mode, the signal handler would be run and it would toggle the
sigwinch_flag variable, preventing the following if to be executed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]