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

[Paul Eggert]

On 09/15/2012 02:32 AM, Eli Zaretskii wrote:

> If someone can describe in detail what SYNC_INPUT means

Sorry, as far as I know, the only detailed description is the source
code itself.  Perhaps Stefan wrote up something sometime....

> I was under the impression that the low-level code to which
> SYNC_INPUT is relevant doesn't need any improvements, because it
> works well enough

It doesn't work well enough in my experience.  I often get crashes
or near-crashes with Emacs.  It'll stop and ask me whether I want
it to abort and dump core, say.  Or it'll just crash.
This sort of thing can be a real problem.  The problem is less
common for me now than it was five years ago, and I credit
SYNC_INPUT for some of that, but it's still too unreliable.

One way I can help improve things is to clean up signal handling,
which is a huge pile of spaghetti at the low level -- it's so
complicated that I expect that hardly anybody understands it.  The
non-SYNC_INPUT code is the worst part of that mess.  If we can
remove it it'd be a real win.  Even if we can disable it
everywhere but on Microsoft platforms, it'd still be a win.

> Calling xmalloc was always safe to invoke from asynchronous entry into
> the display engine, which happens, e.g., when mouse events are
> processed.

That was the intent, yes, but in the non-SYNC_INPUT case it wasn't
really safe.

> let's have BLOCK_INPUT around the call to malloc (and similarly in
> the other related functions).

That can be left in for the Windows case if needed.
But it shouldn't be needed on non-Windows platforms.

> It could be that a better alternative is to leave that code alone,
> if only by replacing the conditionals with WINDOWSNT or some such.

Yes, that's an alternative.  That way, I could still skip the
non-SYNC_INPUT code when auditing signal-handling on POSIXish
platforms.  But it'd be nicer if we could just remove that code.

> it looks like the NS port also uses the !SYNC_INPUT code

Sorry, I don't see why.  'configure --with-ns' does not disable SYNC_INPUT.

> Btw2, your changes remove code conditioned on
> 
>   #if defined SYNC_INPUT || defined USABLE_SIGIO

No, actually, the changes kept that code.  They merely removed the
condition (as it's now always true).

> but do not remove code conditioned on USABLE_SIGIO alone.  Is that
> TRT?

Yes, that sounds right.  USABLE_SIGIO merely means that SIGIO is
usable and SIGIO signals can be handled.  That's not the same
thing as SYNC_INPUT.

> In what ways does the current SYNC_INPUT code get in the way of
> improving Emacs,

The SYNC_INPUT code is not the problem.  It's the non-SYNC_INPUT
code that's dicey.  Generally speaking signal handlers have to be
very disciplined and simple about what they do -- there's only a
small number of function calls that are portable in signal
handlers.  The non-SYNC_INPUT code's signal handlers pretty much
do whatever they want, which leads to races.

> and what kinds of improvement will significantly
> benefit from the proposed changes?

I've been trying to audit the signal handling of Emacs, to help close
race conditions.  Doing this for the non-SYNC_INPUT case is so painful
that I can't imagine anybody doing it.  It should be doable for the
SYNC_INPUT case.  (I'm just talking about POSIXish platforms here; I
don't know about Windows.)