bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized

[Alan Third <alan@idiocy.org>]

On Sun, Mar 11, 2018 at 06:29:05PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Mar 2018 23:07:06 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com
> > 
> > > Can x_set_window_size be called only from redisplay_internal?  If not,
> > > doesn't this risk leaving the updates disabled, if x_set_window_size
> > > is called from some other place?
> > 
> > No, I believe it’s never called from redisplay_internal. 
> 
> Then how do we guarantee that these two calls, one from
> x_set_window_size, the other from redisplay_internal, will be
> balanced, and you never end up with screen updates disabled when you
> don't intend?
> 
> > But x_set_window_size always leaves the frame blank (and there’s no
> > way round that as far as I can see), so there’s not much risk in
> > disabling screen updates until redisplay completes. All we’re doing is
> > preventing the user from seeing a blank frame.
> 
> The question is: can x_set_window_size be called without a redisplay
> happening soon enough, e.g. if Emacs is busy doing some lengthy
> calculation?

OK, so this plan is a non‐starter.

Can I check an assumption I’m making?

Am I able to call redisplay whenever I want? That is, does calling it
ever result in a longjmp?

-- 
Alan Third