nano-devel
[Top][All Lists]
Advanced

[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: Tue, 5 May 2015 11:23:47 +0430

On Tue, May 5, 2015 at 12:37 AM, Benno Schulenberg <address@hidden> wrote:

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

True, but we would need something like this:

    allow_pending_sigwinch(TRUE);
    if (sigwinch_flag_save != sigwinch_flag)
    ....
    while (input = wgetch(win) == ERR)
    ....
    if (sigwinch_flag_save != sigwinch_flag)
    ...

with the first if being the exact duplicate of the second if. Isn't using sigpending()
clearer?
 
> 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: [...]
 
It's not true. You can test it by putting a fprintf(stderr, "foo"); in the sigpending() if.
It sometimes gets executed especially in heavy loops like the file browser provided
that you are dragging the mouse to the left and right very fast. However as I said,
in the normal use, we are almost always in the blocking mode.
 
> > And the remaining allow_pending_sigwinch(FALSE);
> > wouldn't it be more logical to place it after
> > if (sigwinch_flag != sigwinch_flag_save)?

Well, I think I should place it after the while loop. Thanks for mentioning it.

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

Yes, exactly.
 
In that case I reraise my previous suggestion: let the handler
do a sigwinch_flag++.

Ok, I will place allow_pending_sigwinch(FALSE) after the while loop and change
the toggle mechanism in the signal handler to sigwinch_flag++. Is it ok?

Regards,
--

Mahyar

reply via email to

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