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.