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: Paul Eggert
Subject: bug#12450: Remove configure's --without-sync-input option.
Date: Sun, 16 Sep 2012 01:23:28 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0

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.





reply via email to

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