GNU bug report logs - #16967
frame related race condition

Previous Next

Full log

Message #38 received at 16967 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16967 <at> debbugs.gnu.org
Subject: Re: bug#16967: frame related race condition
Date: Tue, 11 Mar 2014 09:07:21 +0100

>> Really?  I was just starting to think otherwise.
>
> ?

Earlier in this thread I wrote that ...

> The fact that this frame has its visibility set to zero at the time
> you `delete-frame' c indicates that we have a pretty awful bug.

... and you agreed by saying ...

>  The fact that this frame has
> > its visibility set to zero at the time you `delete-frame' c indicates
> > that we have a pretty awful bug.

> Yes

... to which I replied ...

> >> The fact that this frame has
> >> its visibility set to zero at the time you `delete-frame' c indicates
> >> that we have a pretty awful bug.
> >
> > Yes
>
> Really?  I was just starting to think otherwise.

... so I was doubting that you really agreed with my judgment of this
bug.

Anyway, the current state of things is IMHO just as bad as it was at the
time you started to write the report for bug 14841.  In particular, the
frame.h hack you mention in that thread

  /* Nonzero if the frame is currently displayed; we check
     it to see if we should bother updating the frame's contents.

     On ttys and on Windows NT/9X, to avoid wasting effort updating
     visible frames that are actually completely obscured by other
     windows on the display, we bend the meaning of visible slightly:
     if equal to 2, then the frame is obscured - we still consider
     it to be "visible" as seen from lisp, but we don't bother
     updating it.  */
  unsigned visible : 2;

is likely responsible for the fact that Emacs doesn't always redisplay a
frame when I remove the window of another application obscuring it.  I'm
still convinced that we should call SET_FRAME_VISIBLE, at least when
f->visible equals 2, in SIZE_RESTORED.  But I'm also convinced that
allowing a value of 2 was bad karma in the first place.  So I see no
other way but reconsidering this design from scratch :-(

BTW: The more I look into this, the more I'm convinced that implementing
frame parameters on top of the old frame infrastructure was one of the
worst design ideas ever.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.