21.5 screen resize issue

[Stephen J. Turnbull]

Ron Isaacson writes:

 > After a resize, I see TWO calls to change_frame_size with the correct
 > dimensions, while delay == 1. Each of these sets the f->new_*
 > variables, along with size_change_pending, then returns. Then there's
 > a THIRD call, again with correct dimensions, when delay == 0; that
 > sets size_change_pending to 0 and then we go through a full redisplay.
 > redisplay_frame does:
 > 
 >   depth = enter_redisplay_critical_section ();
 > 
 > and gets back a depth of 3. It proceeds all the way through the
 > CRITICAL REDISPLAY SECTION, then when it's done, calls:
 > 
 >   exit_redisplay_critical_section (depth);
 > 
 > Now, I confirmed that just before that call, f->size_change_pending is
 > still 0. However, when exit_redisplay_critical_section does its
 > unbind_to business, specpdl_depth_counter starts at 13; by the time it
 > walks down to 3, f->size_change_pending has been reset to 1,

Hm.  I wonder if it's not size_change_pending that has been reset to
1, but rather f has been reset to a frame where size_change_pending is
1!  See the comment about size_change_pending in change_frame_size_1
at line 3437 of frame.c, but in change_frame_size we loop over all TTY
frames without resetting size_change_pending on frames != f at line 3460.

 > but the two f->new_* variables are still 0.

And this may make sense because change_frame_size was called on that
frame from the loop in redisplay.c at line 6719.

I gotta get some sleep, but I think that moving the reset of
size_changed_pending to the beginning of change_frame_size_1 might help.