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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 15 Sep 2012 03:14:50 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: bug-gnu-emacs@gnu.org, lekktu@gmail.com
> 
> 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....

Then how do we know that the changes are correct?  You don't just
remove "#ifdef SYNC_INPUT", you also make additional changes.  E.g.,
what is this about:

> -#ifdef REL_ALLOC
> -  malloc_hysteresis = 32;
> -#else
> -  malloc_hysteresis = 0;
> -#endif

?  If Emacs uses REL_ALLOC, won't it need this?  If this is related to
SYNC_INPUT, please explain how.

> > 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.

I never have such problems on MS-Windows (or anywhere else where I use
Emacs, including on GNU/Linux).  As MS-Windows uses the non-SYNC_INPUT
code, I don't see any evidence for that code being buggy, at least not
on MS-Windows.

> 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.

Or it could be some other, unrelated changes.  With the kind of high
rate of changes we see in Emacs, I don't think it's reasonable to
attribute changes in stability to a single change in the sources,
without a clear evidence.

> 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.

If it works well, there's no need to understand it, is there?  OTOH,
whoever wants to make non-trivial changes in that code _must_
understand it very well.  And you just said you didn't.

> > 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.

Why not?  When is it not safe?

> But [BLOCK_INPUT around malloc calls] shouldn't be needed on
> non-Windows platforms.

Are we absolutely sure?  Can we prove that malloc is never called by
async code?  You don't suggest that, if that assumption is false, we
prefer crashing to blocking input, do you?

> > it looks like the NS port also uses the !SYNC_INPUT code
> 
> Sorry, I don't see why.

Simply because there's HAVE_NS code in there.  For example:

  -#if defined SYNC_INPUT || defined USABLE_SIGIO
   static void
   handle_async_input (void)
   {
     interrupt_input_pending = 0;
  -#ifdef SYNC_INPUT
     pending_signals = pending_atimers;
  -#endif
  -/* Tell ns_read_socket() it is being called asynchronously so it can avoid
  -   doing anything dangerous.  */
  -#ifdef HAVE_NS            <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  -  ++handling_signal;      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  -#endif                    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  +
     while (1)
       {
	 int nread;
  @@ -7199,13 +7178,8 @@
	 if (nread <= 0)
	  break;
       }
  -#ifdef HAVE_NS         <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  -  --handling_signal;   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  -#endif                 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
   }
  -#endif /* SYNC_INPUT || USABLE_SIGIO */

> > 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.

Then don't do that.  Until we have problems that can reliably be
traced to that code, doing so would be a wasted effort, anyway.