bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12450: Remove configure's --without-sync-input option.


From: Eli Zaretskii
Subject: bug#12450: Remove configure's --without-sync-input option.
Date: Sun, 16 Sep 2012 09:10:15 +0300

> Date: Sat, 15 Sep 2012 20:15:36 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: lekktu@gmail.com, 12450@debbugs.gnu.org
> 
> On 09/15/2012 03:18 PM, Richard Stallman wrote:
> > I have a vague memory that the sync input code had an important flaw
> > -- that for certain display-updating tasks (perhaps
> > mouse-highlighting) it could cause a delay until Emacs was read to
> > accept input, which the other code could do instantly.
> > 
> > I don't know if this is true now, and I'm not sure of the memory at all.
> > But it would be good to investigate this question.
> 
> Yes, that topic came up in 2008 when SYNC_INPUT was made the
> default on non-Windows hosts.  That discussion concluded that it's
> not a problem in practice, because SYNC_INPUT does not postpone
> X11 event processing indefinitely; it postpones it only until the
> next QUIT or UNBLOCK_INPUT.  Please see Stefan's comment in
> <http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01368.html>,
> along with the surrounding thread.  The remaining issues noted in
> that thread all seem to have been fixed since then, for the
> SYNC_INPUT case.

That thread left the MS-Windows case indeterminate.

And I still would like to have BLOCK_INPUT in xmalloc and friends,
conditioned on some global variable being non-zero.  That way, if some
strange problems come up, we can ask people to set that variable to a
non-zero value in a debugger and see if the problems persist.  Given
that no one here actually understands all the aspects of the related
issues, that is a prudent thing to do, especially with code freeze and
Emacs 24.3 release looming.





reply via email to

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