GNU bug report logs - #12450
Remove configure's --without-sync-input option.

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Sat, 15 Sep 2012 07:57:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Daniel Colascione <dancol <at> dancol.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org,
	12450 <at> debbugs.gnu.org
Subject: Re: bug#12450: Remove configure's --without-sync-input option.
Date: Sun, 16 Sep 2012 02:52:35 -0700
[Message part 1 (text/plain, inline)]
On 9/16/12 1:23 AM, Paul Eggert wrote:
> On 09/15/2012 11:10 PM, Eli Zaretskii wrote:
>> I still would like to have BLOCK_INPUT in xmalloc and friends,
>> conditioned on some global variable being non-zero.
> 
> There is no need for that, if we've checked our signal handlers to
> make sure that they invoke only async-signal-safe functions.
> 
> Conversely, if we don't check our signal handlers, and we
> are worried that signal handlers might be buggy and might be
> invoking non-async-signal-safe functions, we should put
> debugging wrappers around not only malloc and friends: we
> should wrap every call to every non-async-signal-safe
> function.  But there must be hundreds of such functions, and
> it's not practical to wrap them all.  It's much more practical
> to keep signal handlers small and simple, which is what we've
> already done.
> 
> Leaving BLOCK_INPUT in xmalloc and friends would be a
> revenant of the bad old days when our signal handlers
> invoked the Lisp interpreter and ran random code.  We're
> better off with the standard practice on GNU and POSIXish
> systems for the past four years, which is to not do that.
> That is why removing those BLOCK_INPUTs has long been on our
> TODO list.  What this patch is doing, is marking that job as
> done, because it effectively has been done for four years on
> GNU and POSIXish platforms, and we can do it for MS-Windows
> now.
> 
>> That thread left the MS-Windows case indeterminate.
> 
> OK, but at this point we don't know of any real problems
> that we'd have by assuming SYNC_INPUT on MS-Windows.
> SYNC_INPUT is a much simpler model than non-SYNC_INPUT,
> so this is not surprising.

The cygw32 port uses SYNC_INPUT on Windows. I've been using it for
almost a year in one form or another, and I haven't noticed any
problems. There might be a few lurking bugs, however: one thing that
stands out is that w32term.c, unlike xterm.c, sets
interrupt_input_pending, but doesn't set pending_signals.

[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 12 years and 249 days ago.

Previous Next


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