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

[Benno Schulenberg]

On Mon, May 4, 2015, at 15:49, Mahyar Abbaspour wrote:
> On Mon, May 4, 2015 at 4:38 PM, Benno Schulenberg <address@hidden>
> wrote:
> > 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.

??  But... but...  When the SIGWINCH gets delivered, the handler gets
executed, and the sigwinch_flag gets toggled, so... how are we not
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.

I have removed the section of code, and cannot notice any
adverse effects.  And how could there be?  Whenever we are
resizing the window, we are already in blocking mode: how
could we be dragging the mouse and be typing at the same
time?  (And even if we could, if a SIGWINCH is missed in
that case, let it be missed, nano can't do everything.)

> > 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.

??  You mean the sigwinch_flag would have been toggled twice?
In that case I reraise my previous suggestion: let the handler
do a sigwinch_flag++.

Regards,

Benno

-- 
http://www.fastmail.com - The professional email service