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

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

[Paul Eggert]

When auditing signal-handling in preparation for cleaning it up, I
found that configuring --without-sync-input has race conditions that
look like they would be a real pain to fix.  Many of these involve
memory allocation within a signal handler, which is tricky and
dangerous.  Emacs attempts to work around the problems, but these
workarounds are not sufficient and fixing them would not be easy.

Since it's an undocumented and deprecated configure-time option, and
has been that way for over four years, and the non-SYNC_INPUT code is
a real mess that is getting in the way of improving Emacs, now seems
like a good time to remove that code.  At the end of this message is
the patch that I'd like to install.

I see that nt/config.nt has "#undef SYNC_INPUT" but do the Microsoft
ports care one way or another whether SYNC_INPUT is set?  If so, why?
If not, then that line could simply be removed from nt/config.nt.

I'll CC: this to Eli and Juanma to give them a heads-up.

=== modified file 'ChangeLog'
--- ChangeLog	2012-09-15 07:06:56 +0000
+++ ChangeLog	2012-09-15 07:12:24 +0000
@@ -1,5 +1,8 @@
 2012-09-15  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Remove configure's --without-sync-input option.
+	* configure.ac (SYNC_INPUT, BROKEN_SA_RESTART): Remove.
+
 	Port better to POSIX hosts lacking _setjmp (Bug#12446).
 	* configure.ac (HAVE__SETJMP, HAVE_SIGSETJMP): New symbols.
 	(_setjmp, _longjmp): Remove.

=== modified file 'admin/CPP-DEFINES'
--- admin/CPP-DEFINES	2012-09-13 02:21:28 +0000
+++ admin/CPP-DEFINES	2012-09-15 06:57:23 +0000
@@ -90,7 +90,6 @@
 BROKEN_GET_CURRENT_DIR_NAME
 BROKEN_NON_BLOCKING_CONNECT
 BROKEN_PTY_READ_AFTER_EAGAIN
-BROKEN_SA_RESTART
 CLASH_DETECTION
 DATA_SEG_BITS
 DATA_START
@@ -434,7 +433,6 @@
 PTY_TTY_NAME_SPRINTF
 PURESIZE
 RUN_TIME_REMAP
-SA_RESTART
 SETPGRP_RELEASES_CTTY
 SETUP_SLAVE_PTY
 SIGALRM

=== modified file 'admin/ChangeLog'
--- admin/ChangeLog	2012-09-13 02:21:28 +0000
+++ admin/ChangeLog	2012-09-15 06:57:23 +0000
@@ -1,3 +1,8 @@
+2012-09-15  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Remove configure's --without-sync-input option.
+	* CPP-DEFINES (BROKEN_SA_RESTART, SA_RESTART): Remove.
+
 2012-09-13  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Simplify SIGIO usage (Bug#12408).

=== modified file 'configure.ac'
--- configure.ac	2012-09-15 07:06:56 +0000
+++ configure.ac	2012-09-15 07:12:24 +0000
@@ -128,11 +128,6 @@
 
 OPTION_DEFAULT_ON([sound],[don't compile with sound support])
 
-OPTION_DEFAULT_ON([sync-input],[don't process async input synchronously])
-if test "$with_sync_input" = yes; then
-   AC_DEFINE(SYNC_INPUT, 1, [Process async input synchronously.])
-fi
-
 dnl FIXME currently it is not the last.
 dnl This should be the last --with option, because --with-x is
 dnl added later on when we find the path of X, and it's best to
@@ -3952,11 +3947,6 @@
     ;;
 
   hpux11)
-    dnl See comments in sysdep.c:sys_signal.
-    dnl SA_RESTART resets the timeout of `select' on hpux11.
-    dnl Defining BROKEN_SA_RESTART is not the same as undef'ing SA_RESTART.
-    AC_DEFINE(BROKEN_SA_RESTART, 1, [Define if SA_RESTART should only
-      be used in batch mode.])
     dnl It works to open the pty's tty in the parent (Emacs), then
     dnl close and reopen it in the child.
     AC_DEFINE(USG_SUBTTY_WORKS, 1, [Define for USG systems where it

=== modified file 'etc/ChangeLog'
--- etc/ChangeLog	2012-09-13 16:23:06 +0000
+++ etc/ChangeLog	2012-09-15 06:57:23 +0000
@@ -1,3 +1,9 @@
+2012-09-15  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Remove configure's --without-sync-input option.
+	* TODO (Make SYNC_INPUT the default): Remove, as the code now
+	behaves as if SYNC_INPUT is always true.
+
 2012-09-13  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Use a more backwards-compatible timer format (Bug#12430).

=== modified file 'etc/TODO'
--- etc/TODO	2012-08-04 18:07:50 +0000
+++ etc/TODO	2012-09-15 06:57:23 +0000
@@ -1229,13 +1229,6 @@
    For use by sml-mode, python-mode, tex-mode, scheme-mode, lisp-mode,
    haskell-mode, tuareg-mode, ...
 
-** Make SYNC_INPUT the default. [true since 2008-03-11]
-   All loops using immediate_quit need to be checked to ensure that
-   C-g can interrupt them, in case of an infinite loop.  Once we
-   switch to using SYNC_INPUT, we can remove the BLOCK_INPUTs in the
-   allocation functions (allocate_string etc.) without worrying about
-   data munging.
-
 ** Add "link" button class
    Add a standard button-class named "link", and make all other link-like
    button classes inherit from it.  Set the default face of the "link" button

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-09-15 07:06:56 +0000
+++ src/ChangeLog	2012-09-15 07:12:24 +0000
@@ -1,5 +1,43 @@
 2012-09-15  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Remove configure's --without-sync-input option.
+	When auditing signal-handling in preparation for cleaning it up,
+	I found that SYNC_INPUT has race conditions and would be a real
+	pain to fix.  Since it's an undocumented and deprecated
+	configure-time option, now seems like a good time to remove it.
+	Also see <http://bugs.gnu.org/11080#16>.
+	* alloc.c (_bytes_used, __malloc_extra_blocks, _malloc_internal)
+	(_free_internal) [!DOUG_LEA_MALLOC]: Remove decls.
+	(alloc_mutex, BLOCK_INPUT_ALLOC, UNBLOCK_INPUT_ALLOC)
+	[!SYSTEM_MALLOC && !SYNC_INPUT && HAVE_PTHREAD]:
+	(malloc_hysteresis):
+	(check_depth) [XMALLOC_OVERRUN_CHECK]:
+	(MALLOC_BLOCK_INPUT, MALLOC_UNBLOCK_INPUT):
+	(__malloc_hook, __realloc_hook, __free_hook, BYTES_USED)
+	(dont_register_blocks, bytes_used_when_reconsidered)
+	(bytes_used_when_full, emacs_blocked_free, emacs_blocked_malloc)
+	(emacs_blocked_realloc, reset_malloc_hooks, uninterrupt_malloc):
+	[!SYSTEM_MALLOC && !SYNC_INPUT]:
+	Remove. All uses removed.
+	* atimer.c (run_timers, handle_alarm_signal):
+	* keyboard.c (pending_signal, poll_for_input_1, poll_for_input)
+	(handle_async_input, process_pending_signals)
+	(handle_input_available_signal, init_keyboard):
+	* nsterm.m (ns_read_socket):
+	* process.c (wait_reading_process_output):
+	* regex.c (immediate_quit, IMMEDIATE_QUIT_CHECK):
+	* sysdep.c (emacs_sigaction_init) [SA_RESTART]:
+	(emacs_write):
+	* xterm.c (XTread_socket):
+	Assume SYNC_INPUT.
+	* conf_post.h (SA_RESTART) [IRIX6_5]: Do not #undef.
+	* eval.c (handling_signal): Remove.  All uses removed.
+	* lisp.h (ELSE_PENDING_SIGNALS): Remove.
+	All uses replaced with the SYNC_INPUT version.
+	(reset_malloc_hooks, uninterrupt_malloc, handling_signal): Remove decls.
+	* sysdep.c, syssignal.h (main_thread) [FORWARD_SIGNAL_TO_MAIN_THREAD]:
+	Now static.
+
 	Port better to POSIX hosts lacking _setjmp (Bug#12446).
 	* lisp.h: Include <setjmp.h> here, since we use its symbols here.
 	All instances of '#include <setjmp.h>' removed, if the

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-09-15 07:06:56 +0000
+++ src/alloc.c	2012-09-15 07:12:24 +0000
@@ -85,68 +85,8 @@
 
 #define MMAP_MAX_AREAS 100000000
 
-#else /* not DOUG_LEA_MALLOC */
-
-/* The following come from gmalloc.c.  */
-
-extern size_t _bytes_used;
-extern size_t __malloc_extra_blocks;
-extern void *_malloc_internal (size_t);
-extern void _free_internal (void *);
-
 #endif /* not DOUG_LEA_MALLOC */
 
-#if ! defined SYSTEM_MALLOC && ! defined SYNC_INPUT
-#ifdef HAVE_PTHREAD
-
-# include "syssignal.h"
-
-/* When GTK uses the file chooser dialog, different backends can be loaded
-   dynamically.  One such a backend is the Gnome VFS backend that gets loaded
-   if you run Gnome.  That backend creates several threads and also allocates
-   memory with malloc.
-
-   Also, gconf and gsettings may create several threads.
-
-   If Emacs sets malloc hooks (! SYSTEM_MALLOC) and the emacs_blocked_*
-   functions below are called from malloc, there is a chance that one
-   of these threads preempts the Emacs main thread and the hook variables
-   end up in an inconsistent state.  So we have a mutex to prevent that (note
-   that the backend handles concurrent access to malloc within its own threads
-   but Emacs code running in the main thread is not included in that control).
-
-   When UNBLOCK_INPUT is called, reinvoke_input_signal may be called.  If this
-   happens in one of the backend threads we will have two threads that tries
-   to run Emacs code at once, and the code is not prepared for that.
-   To prevent that, we only call BLOCK/UNBLOCK from the main thread.  */
-
-static pthread_mutex_t alloc_mutex;
-
-#define BLOCK_INPUT_ALLOC                               \
-  do                                                    \
-    {                                                   \
-      if (pthread_equal (pthread_self (), main_thread)) \
-        BLOCK_INPUT;					\
-      pthread_mutex_lock (&alloc_mutex);                \
-    }                                                   \
-  while (0)
-#define UNBLOCK_INPUT_ALLOC                             \
-  do                                                    \
-    {                                                   \
-      pthread_mutex_unlock (&alloc_mutex);              \
-      if (pthread_equal (pthread_self (), main_thread)) \
-        UNBLOCK_INPUT;					\
-    }                                                   \
-  while (0)
-
-#else /* ! defined HAVE_PTHREAD */
-
-#define BLOCK_INPUT_ALLOC BLOCK_INPUT
-#define UNBLOCK_INPUT_ALLOC UNBLOCK_INPUT
-
-#endif /* ! defined HAVE_PTHREAD */
-#endif /* ! defined SYSTEM_MALLOC && ! defined SYNC_INPUT */
-
 /* Mark, unmark, query mark bit of a Lisp string.  S must be a pointer
    to a struct Lisp_String.  */
 
@@ -205,10 +145,6 @@
 
 #define SPARE_MEMORY (1 << 14)
 
-/* Number of extra blocks malloc should get when it needs more core.  */
-
-static int malloc_hysteresis;
-
 /* Initialize it to a nonzero value to force it into data space
    (rather than bss space).  That way unexec will remap it into text
    space (pure), on some systems.  We have not implemented the
@@ -413,12 +349,12 @@
 static void mem_init (void);
 static struct mem_node *mem_insert (void *, void *, enum mem_type);
 static void mem_insert_fixup (struct mem_node *);
-#endif
 static void mem_rotate_left (struct mem_node *);
 static void mem_rotate_right (struct mem_node *);
 static void mem_delete (struct mem_node *);
 static void mem_delete_fixup (struct mem_node *);
 static inline struct mem_node *mem_find (void *);
+#endif
 
 
 #if GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS
@@ -587,39 +523,17 @@
 }
 
 
-/* The call depth in overrun_check functions.  For example, this might happen:
-   xmalloc()
-     overrun_check_malloc()
-       -> malloc -> (via hook)_-> emacs_blocked_malloc
-          -> overrun_check_malloc
-             call malloc  (hooks are NULL, so real malloc is called).
-             malloc returns 10000.
-             add overhead, return 10016.
-      <- (back in overrun_check_malloc)
-      add overhead again, return 10032
-   xmalloc returns 10032.
-
-   (time passes).
-
-   xfree(10032)
-     overrun_check_free(10032)
-       decrease overhead
-       free(10016)  <-  crash, because 10000 is the original pointer.  */
-
-static ptrdiff_t check_depth;
-
 /* Like malloc, but wraps allocated block with header and trailer.  */
 
 static void *
 overrun_check_malloc (size_t size)
 {
   register unsigned char *val;
-  int overhead = ++check_depth == 1 ? XMALLOC_OVERRUN_CHECK_OVERHEAD : 0;
-  if (SIZE_MAX - overhead < size)
+  if (SIZE_MAX - XMALLOC_OVERRUN_CHECK_OVERHEAD < size)
     emacs_abort ();
 
-  val = malloc (size + overhead);
-  if (val && check_depth == 1)
+  val = malloc (size + XMALLOC_OVERRUN_CHECK_OVERHEAD);
+  if (val)
     {
       memcpy (val, xmalloc_overrun_check_header, XMALLOC_OVERRUN_CHECK_SIZE);
       val += XMALLOC_OVERRUN_CHECK_SIZE + XMALLOC_OVERRUN_SIZE_SIZE;
@@ -627,7 +541,6 @@
       memcpy (val + size, xmalloc_overrun_check_trailer,
 	      XMALLOC_OVERRUN_CHECK_SIZE);
     }
-  --check_depth;
   return val;
 }
 
@@ -639,12 +552,10 @@
 overrun_check_realloc (void *block, size_t size)
 {
   register unsigned char *val = (unsigned char *) block;
-  int overhead = ++check_depth == 1 ? XMALLOC_OVERRUN_CHECK_OVERHEAD : 0;
-  if (SIZE_MAX - overhead < size)
+  if (SIZE_MAX - XMALLOC_OVERRUN_CHECK_OVERHEAD < size)
     emacs_abort ();
 
   if (val
-      && check_depth == 1
       && memcmp (xmalloc_overrun_check_header,
 		 val - XMALLOC_OVERRUN_CHECK_SIZE - XMALLOC_OVERRUN_SIZE_SIZE,
 		 XMALLOC_OVERRUN_CHECK_SIZE) == 0)
@@ -658,9 +569,9 @@
       memset (val, 0, XMALLOC_OVERRUN_CHECK_SIZE + XMALLOC_OVERRUN_SIZE_SIZE);
     }
 
-  val = realloc (val, size + overhead);
+  val = realloc (val, size + XMALLOC_OVERRUN_CHECK_OVERHEAD);
 
-  if (val && check_depth == 1)
+  if (val)
     {
       memcpy (val, xmalloc_overrun_check_header, XMALLOC_OVERRUN_CHECK_SIZE);
       val += XMALLOC_OVERRUN_CHECK_SIZE + XMALLOC_OVERRUN_SIZE_SIZE;
@@ -668,7 +579,6 @@
       memcpy (val + size, xmalloc_overrun_check_trailer,
 	      XMALLOC_OVERRUN_CHECK_SIZE);
     }
-  --check_depth;
   return val;
 }
 
@@ -679,9 +589,7 @@
 {
   unsigned char *val = (unsigned char *) block;
 
-  ++check_depth;
   if (val
-      && check_depth == 1
       && memcmp (xmalloc_overrun_check_header,
 		 val - XMALLOC_OVERRUN_CHECK_SIZE - XMALLOC_OVERRUN_SIZE_SIZE,
 		 XMALLOC_OVERRUN_CHECK_SIZE) == 0)
@@ -701,7 +609,6 @@
     }
 
   free (val);
-  --check_depth;
 }
 
 #undef malloc
@@ -712,27 +619,12 @@
 #define free overrun_check_free
 #endif
 
-#ifdef SYNC_INPUT
-/* When using SYNC_INPUT, we don't call malloc from a signal handler, so
-   there's no need to block input around malloc.  */
-#define MALLOC_BLOCK_INPUT   ((void)0)
-#define MALLOC_UNBLOCK_INPUT ((void)0)
-#else
-#define MALLOC_BLOCK_INPUT   BLOCK_INPUT
-#define MALLOC_UNBLOCK_INPUT UNBLOCK_INPUT
-#endif
-
 /* Like malloc but check for no memory and block interrupt input..  */
 
 void *
 xmalloc (size_t size)
 {
-  void *val;
-
-  MALLOC_BLOCK_INPUT;
-  val = malloc (size);
-  MALLOC_UNBLOCK_INPUT;
-
+  void *val = malloc (size);
   if (!val && size)
     memory_full (size);
   return val;
@@ -743,12 +635,7 @@
 void *
 xzalloc (size_t size)
 {
-  void *val;
-
-  MALLOC_BLOCK_INPUT;
-  val = malloc (size);
-  MALLOC_UNBLOCK_INPUT;
-
+  void *val = malloc (size);
   if (!val && size)
     memory_full (size);
   memset (val, 0, size);
@@ -762,14 +649,12 @@
 {
   void *val;
 
-  MALLOC_BLOCK_INPUT;
   /* We must call malloc explicitly when BLOCK is 0, since some
      reallocs don't do this.  */
   if (! block)
     val = malloc (size);
   else
     val = realloc (block, size);
-  MALLOC_UNBLOCK_INPUT;
 
   if (!val && size)
     memory_full (size);
@@ -784,12 +669,9 @@
 {
   if (!block)
     return;
-  MALLOC_BLOCK_INPUT;
   free (block);
-  MALLOC_UNBLOCK_INPUT;
   /* We don't call refill_memory_reserve here
-     because that duplicates doing so in emacs_blocked_free
-     and the criterion should go there.  */
+     because in practice the call in r_alloc_free seems to suffice.  */
 }
 
 
@@ -930,8 +812,6 @@
 {
   register void *val;
 
-  MALLOC_BLOCK_INPUT;
-
 #ifdef GC_MALLOC_CHECK
   allocated_mem_type = type;
 #endif
@@ -960,7 +840,6 @@
     mem_insert (val, (char *) val + nbytes, type);
 #endif
 
-  MALLOC_UNBLOCK_INPUT;
   if (!val && nbytes)
     memory_full (nbytes);
   return val;
@@ -972,12 +851,10 @@
 static void
 lisp_free (void *block)
 {
-  MALLOC_BLOCK_INPUT;
   free (block);
 #if GC_MARK_STACK && !defined GC_MALLOC_CHECK
   mem_delete (mem_find (block));
 #endif
-  MALLOC_UNBLOCK_INPUT;
 }
 
 /*****  Allocation of aligned blocks of memory to store Lisp data.  *****/
@@ -1074,8 +951,6 @@
 
   eassert (nbytes <= BLOCK_BYTES);
 
-  MALLOC_BLOCK_INPUT;
-
 #ifdef GC_MALLOC_CHECK
   allocated_mem_type = type;
 #endif
@@ -1105,10 +980,7 @@
 #endif
 
       if (base == 0)
-	{
-	  MALLOC_UNBLOCK_INPUT;
-	  memory_full (ABLOCKS_BYTES);
-	}
+	memory_full (ABLOCKS_BYTES);
 
       aligned = (base == abase);
       if (!aligned)
@@ -1132,7 +1004,6 @@
 	    {
 	      lisp_malloc_loser = base;
 	      free (base);
-	      MALLOC_UNBLOCK_INPUT;
 	      memory_full (SIZE_MAX);
 	    }
 	}
@@ -1166,8 +1037,6 @@
     mem_insert (val, (char *) val + nbytes, type);
 #endif
 
-  MALLOC_UNBLOCK_INPUT;
-
   eassert (0 == ((uintptr_t) val) % BLOCK_ALIGN);
   return val;
 }
@@ -1178,7 +1047,6 @@
   struct ablock *ablock = block;
   struct ablocks *abase = ABLOCK_ABASE (ablock);
 
-  MALLOC_BLOCK_INPUT;
 #if GC_MARK_STACK && !defined GC_MALLOC_CHECK
   mem_delete (mem_find (block));
 #endif
@@ -1212,258 +1080,7 @@
 #endif
       free (ABLOCKS_BASE (abase));
     }
-  MALLOC_UNBLOCK_INPUT;
-}
-
-\f
-#ifndef SYSTEM_MALLOC
-
-/* Arranging to disable input signals while we're in malloc.
-
-   This only works with GNU malloc.  To help out systems which can't
-   use GNU malloc, all the calls to malloc, realloc, and free
-   elsewhere in the code should be inside a BLOCK_INPUT/UNBLOCK_INPUT
-   pair; unfortunately, we have no idea what C library functions
-   might call malloc, so we can't really protect them unless you're
-   using GNU malloc.  Fortunately, most of the major operating systems
-   can use GNU malloc.  */
-
-#ifndef SYNC_INPUT
-/* When using SYNC_INPUT, we don't call malloc from a signal handler, so
-   there's no need to block input around malloc.  */
-
-#ifndef DOUG_LEA_MALLOC
-extern void * (*__malloc_hook) (size_t, const void *);
-extern void * (*__realloc_hook) (void *, size_t, const void *);
-extern void (*__free_hook) (void *, const void *);
-/* Else declared in malloc.h, perhaps with an extra arg.  */
-#endif /* DOUG_LEA_MALLOC */
-static void * (*old_malloc_hook) (size_t, const void *);
-static void * (*old_realloc_hook) (void *,  size_t, const void*);
-static void (*old_free_hook) (void*, const void*);
-
-#ifdef DOUG_LEA_MALLOC
-#  define BYTES_USED (mallinfo ().uordblks)
-#else
-#  define BYTES_USED _bytes_used
-#endif
-
-#ifdef GC_MALLOC_CHECK
-static bool dont_register_blocks;
-#endif
-
-static size_t bytes_used_when_reconsidered;
-
-/* Value of _bytes_used, when spare_memory was freed.  */
-
-static size_t bytes_used_when_full;
-
-/* This function is used as the hook for free to call.  */
-
-static void
-emacs_blocked_free (void *ptr, const void *ptr2)
-{
-  BLOCK_INPUT_ALLOC;
-
-#ifdef GC_MALLOC_CHECK
-  if (ptr)
-    {
-      struct mem_node *m;
-
-      m = mem_find (ptr);
-      if (m == MEM_NIL || m->start != ptr)
-	{
-	  fprintf (stderr,
-		   "Freeing `%p' which wasn't allocated with malloc\n", ptr);
-	  emacs_abort ();
-	}
-      else
-	{
-	  /* fprintf (stderr, "free %p...%p (%p)\n", m->start, m->end, ptr); */
-	  mem_delete (m);
-	}
-    }
-#endif /* GC_MALLOC_CHECK */
-
-  __free_hook = old_free_hook;
-  free (ptr);
-
-  /* If we released our reserve (due to running out of memory),
-     and we have a fair amount free once again,
-     try to set aside another reserve in case we run out once more.  */
-  if (! NILP (Vmemory_full)
-      /* Verify there is enough space that even with the malloc
-	 hysteresis this call won't run out again.
-	 The code here is correct as long as SPARE_MEMORY
-	 is substantially larger than the block size malloc uses.  */
-      && (bytes_used_when_full
-	  > ((bytes_used_when_reconsidered = BYTES_USED)
-	     + max (malloc_hysteresis, 4) * SPARE_MEMORY)))
-    refill_memory_reserve ();
-
-  __free_hook = emacs_blocked_free;
-  UNBLOCK_INPUT_ALLOC;
-}
-
-
-/* This function is the malloc hook that Emacs uses.  */
-
-static void *
-emacs_blocked_malloc (size_t size, const void *ptr)
-{
-  void *value;
-
-  BLOCK_INPUT_ALLOC;
-  __malloc_hook = old_malloc_hook;
-#ifdef DOUG_LEA_MALLOC
-  /* Segfaults on my system.  --lorentey */
-  /* mallopt (M_TOP_PAD, malloc_hysteresis * 4096); */
-#else
-    __malloc_extra_blocks = malloc_hysteresis;
-#endif
-
-  value = malloc (size);
-
-#ifdef GC_MALLOC_CHECK
-  {
-    struct mem_node *m = mem_find (value);
-    if (m != MEM_NIL)
-      {
-	fprintf (stderr, "Malloc returned %p which is already in use\n",
-		 value);
-	fprintf (stderr, "Region in use is %p...%p, %td bytes, type %d\n",
-		 m->start, m->end, (char *) m->end - (char *) m->start,
-		 m->type);
-	emacs_abort ();
-      }
-
-    if (!dont_register_blocks)
-      {
-	mem_insert (value, (char *) value + max (1, size), allocated_mem_type);
-	allocated_mem_type = MEM_TYPE_NON_LISP;
-      }
-  }
-#endif /* GC_MALLOC_CHECK */
-
-  __malloc_hook = emacs_blocked_malloc;
-  UNBLOCK_INPUT_ALLOC;
-
-  /* fprintf (stderr, "%p malloc\n", value); */
-  return value;
-}
-
-
-/* This function is the realloc hook that Emacs uses.  */
-
-static void *
-emacs_blocked_realloc (void *ptr, size_t size, const void *ptr2)
-{
-  void *value;
-
-  BLOCK_INPUT_ALLOC;
-  __realloc_hook = old_realloc_hook;
-
-#ifdef GC_MALLOC_CHECK
-  if (ptr)
-    {
-      struct mem_node *m = mem_find (ptr);
-      if (m == MEM_NIL || m->start != ptr)
-	{
-	  fprintf (stderr,
-		   "Realloc of %p which wasn't allocated with malloc\n",
-		   ptr);
-	  emacs_abort ();
-	}
-
-      mem_delete (m);
-    }
-
-  /* fprintf (stderr, "%p -> realloc\n", ptr); */
-
-  /* Prevent malloc from registering blocks.  */
-  dont_register_blocks = 1;
-#endif /* GC_MALLOC_CHECK */
-
-  value = realloc (ptr, size);
-
-#ifdef GC_MALLOC_CHECK
-  dont_register_blocks = 0;
-
-  {
-    struct mem_node *m = mem_find (value);
-    if (m != MEM_NIL)
-      {
-	fprintf (stderr, "Realloc returns memory that is already in use\n");
-	emacs_abort ();
-      }
-
-    /* Can't handle zero size regions in the red-black tree.  */
-    mem_insert (value, (char *) value + max (size, 1), MEM_TYPE_NON_LISP);
-  }
-
-  /* fprintf (stderr, "%p <- realloc\n", value); */
-#endif /* GC_MALLOC_CHECK */
-
-  __realloc_hook = emacs_blocked_realloc;
-  UNBLOCK_INPUT_ALLOC;
-
-  return value;
-}
-
-
-#ifdef HAVE_PTHREAD
-/* Called from Fdump_emacs so that when the dumped Emacs starts, it has a
-   normal malloc.  Some thread implementations need this as they call
-   malloc before main.  The pthread_self call in BLOCK_INPUT_ALLOC then
-   calls malloc because it is the first call, and we have an endless loop.  */
-
-void
-reset_malloc_hooks (void)
-{
-  __free_hook = old_free_hook;
-  __malloc_hook = old_malloc_hook;
-  __realloc_hook = old_realloc_hook;
-}
-#endif /* HAVE_PTHREAD */
-
-
-/* Called from main to set up malloc to use our hooks.  */
-
-void
-uninterrupt_malloc (void)
-{
-#ifdef HAVE_PTHREAD
-#ifdef DOUG_LEA_MALLOC
-  pthread_mutexattr_t attr;
-
-  /*  GLIBC has a faster way to do this, but let's keep it portable.
-      This is according to the Single UNIX Specification.  */
-  pthread_mutexattr_init (&attr);
-  pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
-  pthread_mutex_init (&alloc_mutex, &attr);
-#else  /* !DOUG_LEA_MALLOC */
-  /* Some systems such as Solaris 2.6 don't have a recursive mutex,
-     and the bundled gmalloc.c doesn't require it.  */
-  pthread_mutex_init (&alloc_mutex, NULL);
-#endif /* !DOUG_LEA_MALLOC */
-#endif /* HAVE_PTHREAD */
-
-  if (__free_hook != emacs_blocked_free)
-    old_free_hook = __free_hook;
-  __free_hook = emacs_blocked_free;
-
-  if (__malloc_hook != emacs_blocked_malloc)
-    old_malloc_hook = __malloc_hook;
-  __malloc_hook = emacs_blocked_malloc;
-
-  if (__realloc_hook != emacs_blocked_realloc)
-    old_realloc_hook = __realloc_hook;
-  __realloc_hook = emacs_blocked_realloc;
-}
-
-#endif /* not SYNC_INPUT */
-#endif /* not SYSTEM_MALLOC */
-
+}
 
 \f
 /***********************************************************************
@@ -1511,10 +1128,6 @@
 {
   INTERVAL val;
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   if (interval_free_list)
     {
       val = interval_free_list;
@@ -1535,8 +1148,6 @@
       val = &interval_block->intervals[interval_block_index++];
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   consing_since_gc += sizeof (struct interval);
   intervals_consed++;
   total_free_intervals--;
@@ -1896,10 +1507,6 @@
 {
   struct Lisp_String *s;
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   /* If the free-list is empty, allocate a new string_block, and
      add all the Lisp_Strings in it to the free-list.  */
   if (string_free_list == NULL)
@@ -1928,8 +1535,6 @@
   s = string_free_list;
   string_free_list = NEXT_FREE_LISP_STRING (s);
 
-  MALLOC_UNBLOCK_INPUT;
-
   --total_free_strings;
   ++total_strings;
   ++strings_consed;
@@ -1980,8 +1585,6 @@
   else
     old_data = NULL;
 
-  MALLOC_BLOCK_INPUT;
-
   if (nbytes > LARGE_STRING_BYTES)
     {
       size_t size = offsetof (struct sblock, first_data) + needed;
@@ -2034,8 +1637,6 @@
   data = b->next_free;
   b->next_free = (struct sdata *) ((char *) data + needed + GC_STRING_EXTRA);
 
-  MALLOC_UNBLOCK_INPUT;
-
   data->string = s;
   s->data = SDATA_DATA (data);
 #ifdef GC_CHECK_STRING_BYTES
@@ -2589,10 +2190,6 @@
 {
   register Lisp_Object val;
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   if (float_free_list)
     {
       /* We use the data field for chaining the free list
@@ -2616,8 +2213,6 @@
       float_block_index++;
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   XFLOAT_INIT (val, float_value);
   eassert (!FLOAT_MARKED_P (XFLOAT (val)));
   consing_since_gc += sizeof (struct Lisp_Float);
@@ -2698,10 +2293,6 @@
 {
   register Lisp_Object val;
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   if (cons_free_list)
     {
       /* We use the cdr for chaining the free list
@@ -2725,8 +2316,6 @@
       cons_block_index++;
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   XSETCAR (val, car);
   XSETCDR (val, cdr);
   eassert (!CONS_MARKED_P (XCONS (val)));
@@ -3203,11 +2792,6 @@
 {
   struct Lisp_Vector *p;
 
-  MALLOC_BLOCK_INPUT;
-
-  /* This gets triggered by code which I haven't bothered to fix.  --Stef  */
-  /* eassert (!handling_signal); */
-
   if (len == 0)
     p = XVECTOR (zero_vector);
   else
@@ -3239,8 +2823,6 @@
       vector_cells_consed += len;
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   return p;
 }
 
@@ -3492,10 +3074,6 @@
 
   CHECK_STRING (name);
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   if (symbol_free_list)
     {
       XSETSYMBOL (val, symbol_free_list);
@@ -3516,8 +3094,6 @@
       symbol_block_index++;
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   p = XSYMBOL (val);
   set_symbol_name (val, name);
   set_symbol_plist (val, Qnil);
@@ -3578,10 +3154,6 @@
 {
   Lisp_Object val;
 
-  /* eassert (!handling_signal); */
-
-  MALLOC_BLOCK_INPUT;
-
   if (marker_free_list)
     {
       XSETMISC (val, marker_free_list);
@@ -3601,8 +3173,6 @@
       marker_block_index++;
     }
 
-  MALLOC_UNBLOCK_INPUT;
-
   --total_free_markers;
   consing_since_gc += sizeof (union Lisp_Misc);
   misc_objects_consed++;
@@ -3767,16 +3337,12 @@
   bool enough_free_memory = 0;
   if (SPARE_MEMORY < nbytes)
     {
-      void *p;
-
-      MALLOC_BLOCK_INPUT;
-      p = malloc (SPARE_MEMORY);
+      void *p = malloc (SPARE_MEMORY);
       if (p)
 	{
 	  free (p);
 	  enough_free_memory = 1;
 	}
-      MALLOC_UNBLOCK_INPUT;
     }
 
   if (! enough_free_memory)
@@ -3799,12 +3365,6 @@
 	      lisp_free (spare_memory[i]);
 	    spare_memory[i] = 0;
 	  }
-
-      /* Record the space now used.  When it decreases substantially,
-	 we can refill the memory reserve.  */
-#if !defined SYSTEM_MALLOC && !defined SYNC_INPUT
-      bytes_used_when_full = BYTES_USED;
-#endif
     }
 
   /* This used to call error, but if we've run out of memory, we could
@@ -3942,7 +3502,7 @@
 
   /* Create a new node.  */
 #ifdef GC_MALLOC_CHECK
-  x = _malloc_internal (sizeof *x);
+  x = malloc (sizeof *x);
   if (x == NULL)
     emacs_abort ();
 #else
@@ -4166,7 +3726,7 @@
     mem_delete_fixup (x);
 
 #ifdef GC_MALLOC_CHECK
-  _free_internal (y);
+  free (y);
 #else
   xfree (y);
 #endif
@@ -6767,12 +6327,6 @@
   init_strings ();
   init_vectors ();
 
-#ifdef REL_ALLOC
-  malloc_hysteresis = 32;
-#else
-  malloc_hysteresis = 0;
-#endif
-
   refill_memory_reserve ();
   gc_cons_threshold = GC_DEFAULT_THRESHOLD;
 }

=== modified file 'src/atimer.c'
--- src/atimer.c	2012-09-15 07:06:56 +0000
+++ src/atimer.c	2012-09-15 07:12:24 +0000
@@ -369,7 +369,6 @@
   if (! atimers)
     pending_atimers = 0;
 
-#ifdef SYNC_INPUT
   if (pending_atimers)
     pending_signals = 1;
   else
@@ -377,10 +376,6 @@
       pending_signals = interrupt_input_pending;
       set_alarm ();
     }
-#else
-  if (! pending_atimers)
-    set_alarm ();
-#endif
 }
 
 
@@ -391,11 +386,7 @@
 handle_alarm_signal (int sig)
 {
   pending_atimers = 1;
-#ifdef SYNC_INPUT
   pending_signals = 1;
-#else
-  run_timers ();
-#endif
 }
 
 static void

=== modified file 'src/bytecode.c'
--- src/bytecode.c	2012-09-15 07:06:56 +0000
+++ src/bytecode.c	2012-09-15 07:12:24 +0000
@@ -458,7 +458,8 @@
 	Fsignal (Qquit, Qnil);				\
 	AFTER_POTENTIAL_GC ();				\
       }							\
-    ELSE_PENDING_SIGNALS				\
+    else if (pending_signals)				\
+      process_pending_signals ();			\
   } while (0)
 
 

=== modified file 'src/conf_post.h'
--- src/conf_post.h	2012-09-13 02:21:28 +0000
+++ src/conf_post.h	2012-09-15 06:57:23 +0000
@@ -90,7 +90,6 @@
 char *_getpty();
 #endif
 
-#undef SA_RESTART     /* not the same as defining BROKEN_SA_RESTART */
 #endif /* IRIX6_5 */
 
 #ifdef MSDOS

=== modified file 'src/emacs.c'
--- src/emacs.c	2012-09-15 07:06:56 +0000
+++ src/emacs.c	2012-09-15 07:12:24 +0000
@@ -848,14 +848,10 @@
   /* Arrange to get warning messages as memory fills up.  */
   memory_warnings (0, malloc_warning);
 
-  /* Call malloc at least once, to run the initial __malloc_hook.
+  /* Call malloc at least once, to run malloc_initialize_hook.
      Also call realloc and free for consistency.  */
   free (realloc (malloc (4), 4));
 
-# ifndef SYNC_INPUT
-  /* Arrange to disable interrupt input inside malloc etc.  */
-  uninterrupt_malloc ();
-# endif /* not SYNC_INPUT */
 #endif	/* not SYSTEM_MALLOC */
 
 #if defined (MSDOS) || defined (WINDOWSNT)
@@ -2143,12 +2139,6 @@
     memory_warnings (my_edata, malloc_warning);
   }
 #endif /* not WINDOWSNT */
-#if defined (HAVE_PTHREAD) && !defined SYNC_INPUT
-  /* Pthread may call malloc before main, and then we will get an endless
-     loop, because pthread_self (see alloc.c) calls malloc the first time
-     it is called on some systems.  */
-  reset_malloc_hooks ();
-#endif
 #endif /* not SYSTEM_MALLOC */
 #ifdef DOUG_LEA_MALLOC
   malloc_state_ptr = malloc_get_state ();

=== modified file 'src/eval.c'
--- src/eval.c	2012-09-15 07:06:56 +0000
+++ src/eval.c	2012-09-15 07:12:24 +0000
@@ -117,12 +117,6 @@
 
 Lisp_Object Vsignaling_function;
 
-/* Set to non-zero while processing X events.  Checked in Feval to
-   make sure the Lisp interpreter isn't called from a signal handler,
-   which is unsafe because the interpreter isn't reentrant.  */
-
-int handling_signal;
-
 /* If non-nil, Lisp code must not be run since some part of Emacs is
    in an inconsistent state.  Currently, x-create-frame uses this to
    avoid triggering window-configuration-change-hook while the new
@@ -1106,7 +1100,6 @@
   /* Restore certain special C variables.  */
   set_poll_suppress_count (catch->poll_suppress_count);
   UNBLOCK_INPUT_TO (catch->interrupt_input_blocked);
-  handling_signal = 0;
   immediate_quit = 0;
 
   do
@@ -1486,7 +1479,7 @@
   struct handler *h;
   struct backtrace *bp;
 
-  immediate_quit = handling_signal = 0;
+  immediate_quit = 0;
   abort_on_gc = 0;
   if (gc_in_progress || waiting_for_input)
     emacs_abort ();
@@ -2039,9 +2032,6 @@
   struct backtrace backtrace;
   struct gcpro gcpro1, gcpro2, gcpro3;
 
-  if (handling_signal)
-    emacs_abort ();
-
   if (SYMBOLP (form))
     {
       /* Look up its binding in the lexical environment.
@@ -3104,8 +3094,6 @@
 {
   struct Lisp_Symbol *sym;
 
-  eassert (!handling_signal);
-
   CHECK_SYMBOL (symbol);
   sym = XSYMBOL (symbol);
   if (specpdl_ptr == specpdl + specpdl_size)
@@ -3199,8 +3187,6 @@
 void
 record_unwind_protect (Lisp_Object (*function) (Lisp_Object), Lisp_Object arg)
 {
-  eassert (!handling_signal);
-
   if (specpdl_ptr == specpdl + specpdl_size)
     grow_specpdl ();
   specpdl_ptr->func = function;

=== modified file 'src/intervals.c'
--- src/intervals.c	2012-09-15 07:06:56 +0000
+++ src/intervals.c	2012-09-15 07:12:24 +0000
@@ -673,8 +673,7 @@
 
   eassert (relative_position <= TOTAL_LENGTH (tree));
 
-  if (!handling_signal)
-    tree = balance_possible_root_interval (tree);
+  tree = balance_possible_root_interval (tree);
 
   while (1)
     {

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2012-09-15 07:06:56 +0000
+++ src/keyboard.c	2012-09-15 07:12:24 +0000
@@ -84,9 +84,7 @@
    pending_atimers separately, to reduce code size.  So, any code that
    changes interrupt_input_pending or pending_atimers should update
    this too.  */
-#ifdef SYNC_INPUT
 int pending_signals;
-#endif
 
 #define KBD_BUFFER_SIZE 4096
 
@@ -2010,17 +2008,9 @@
 void
 poll_for_input_1 (void)
 {
-/* Tell ns_read_socket() it is being called asynchronously so it can avoid
-   doing anything dangerous.  */
-#ifdef HAVE_NS
-  ++handling_signal;
-#endif
   if (interrupt_input_blocked == 0
       && !waiting_for_input)
     read_avail_input (0);
-#ifdef HAVE_NS
-  --handling_signal;
-#endif
 }
 
 /* Timer callback function for poll_timer.  TIMER is equal to
@@ -2031,12 +2021,8 @@
 {
   if (poll_suppress_count == 0)
     {
-#ifdef SYNC_INPUT
       interrupt_input_pending = 1;
       pending_signals = 1;
-#else
-      poll_for_input_1 ();
-#endif
     }
 }
 
@@ -7176,19 +7162,12 @@
   return nread;
 }
 \f
-#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 */
 
-#ifdef SYNC_INPUT
 void
 process_pending_signals (void)
 {
@@ -7213,24 +7187,17 @@
     handle_async_input ();
   do_pending_atimers ();
 }
-#endif
 
 #ifdef USABLE_SIGIO
 
 static void
 handle_input_available_signal (int sig)
 {
-#ifdef SYNC_INPUT
   interrupt_input_pending = 1;
   pending_signals = 1;
-#endif
 
   if (input_available_clear_time)
     *input_available_clear_time = make_emacs_time (0, 0);
-
-#ifndef SYNC_INPUT
-  handle_async_input ();
-#endif
 }
 
 static void
@@ -11365,9 +11332,7 @@
   input_pending = 0;
   interrupt_input_blocked = 0;
   interrupt_input_pending = 0;
-#ifdef SYNC_INPUT
   pending_signals = 0;
-#endif
 
   /* This means that command_loop_1 won't try to select anything the first
      time through.  */

=== modified file 'src/lisp.h'
--- src/lisp.h	2012-09-15 07:06:56 +0000
+++ src/lisp.h	2012-09-15 07:12:24 +0000
@@ -2106,22 +2106,16 @@
    If quit-flag is set to `kill-emacs' the SIGINT handler has received
    a request to exit Emacs when it is safe to do.  */
 
-#ifdef SYNC_INPUT
 extern void process_pending_signals (void);
 extern int pending_signals;
-#define ELSE_PENDING_SIGNALS				\
-  else if (pending_signals)				\
-    process_pending_signals ();
-#else  /* not SYNC_INPUT */
-#define ELSE_PENDING_SIGNALS
-#endif	/* not SYNC_INPUT */
 
 extern void process_quit_flag (void);
 #define QUIT						\
   do {							\
     if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
       process_quit_flag ();				\
-    ELSE_PENDING_SIGNALS				\
+    else if (pending_signals)				\
+      process_pending_signals ();			\
   } while (0)
 
 
@@ -2845,8 +2839,6 @@
 /* Defined in alloc.c.  */
 extern void check_pure_size (void);
 extern void allocate_string_data (struct Lisp_String *, EMACS_INT, EMACS_INT);
-extern void reset_malloc_hooks (void);
-extern void uninterrupt_malloc (void);
 extern void malloc_warning (const char *);
 extern _Noreturn void memory_full (size_t);
 extern _Noreturn void buffer_memory_full (ptrdiff_t);
@@ -3042,7 +3034,6 @@
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vsignaling_function;
 extern Lisp_Object inhibit_lisp_code;
-extern int handling_signal;
 #if BYTE_MARK_STACK
 extern struct catchtag *catchlist;
 extern struct handler *handlerlist;

=== modified file 'src/nsmenu.m'
--- src/nsmenu.m	2012-09-15 07:06:56 +0000
+++ src/nsmenu.m	2012-09-15 07:12:24 +0000
@@ -588,10 +588,7 @@
      From 10.6 on, we could also use -[NSMenu propertiesToUpdate]: In the
      key press case, NSMenuPropertyItemImage (e.g.) won't be set.
   */
-  if (trackingMenu == 0
-      /* Also, don't try this if from an event picked up asynchronously,
-         as lots of lisp evaluation happens in ns_update_menubar. */
-      || handling_signal != 0)
+  if (trackingMenu == 0)
     return;
 /*fprintf (stderr, "Updating menu '%s'\n", [[self title] UTF8String]); NSLog (@"%@\n", event); */
   ns_update_menubar (frame, 1, self);

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2012-09-15 07:06:56 +0000
+++ src/nsterm.m	2012-09-15 07:12:24 +0000
@@ -3354,16 +3354,12 @@
   if (interrupt_input_blocked)
     {
       interrupt_input_pending = 1;
-#ifdef SYNC_INPUT
       pending_signals = 1;
-#endif
       return -1;
     }
 
   interrupt_input_pending = 0;
-#ifdef SYNC_INPUT
   pending_signals = pending_atimers;
-#endif
 
   BLOCK_INPUT;
   n_emacs_events_pending = 0;
@@ -3725,7 +3721,7 @@
       removed = YES;
     }
 
-  if (removed) 
+  if (removed)
     [eview updateFrameSize: NO];
 }
 
@@ -3981,7 +3977,6 @@
   /* count object allocs (About, click icon); on OS X use ObjectAlloc tool */
   /*GSDebugAllocationActive (YES); */
   BLOCK_INPUT;
-  handling_signal = 0;
 
   if (!ns_initialized)
     {
@@ -6222,7 +6217,7 @@
       NSRect r = [super constrainFrameRect:frameRect toScreen:screen];
       return r;
     }
-  
+
   if (f->output_data.ns->dont_constrain
       || ns_menu_bar_should_be_hidden ())
     return frameRect;

=== modified file 'src/process.c'
--- src/process.c	2012-09-15 07:06:56 +0000
+++ src/process.c	2012-09-15 07:12:24 +0000
@@ -4395,10 +4395,8 @@
 	 Otherwise, do pending quit if requested.  */
       if (read_kbd >= 0)
 	QUIT;
-#ifdef SYNC_INPUT
       else
 	process_pending_signals ();
-#endif
 
       /* Exit now if the cell we're waiting for became non-nil.  */
       if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))

=== modified file 'src/regex.c'
--- src/regex.c	2012-09-15 07:06:56 +0000
+++ src/regex.c	2012-09-15 07:12:24 +0000
@@ -1831,9 +1831,9 @@
 /* The next available element.  */
 #define COMPILE_STACK_TOP (compile_stack.stack[compile_stack.avail])
 
-/* Explicit quit checking is only used on NTemacs and whenever we
-   use polling to process input events.  */
-#if defined emacs && (defined WINDOWSNT || defined SYNC_INPUT) && defined QUIT
+/* Explicit quit checking is needed for Emacs, which uses polling to
+   process input events.  */
+#ifdef emacs
 extern int immediate_quit;
 # define IMMEDIATE_QUIT_CHECK			\
     do {					\

=== modified file 'src/sysdep.c'
--- src/sysdep.c	2012-09-15 07:06:56 +0000
+++ src/sysdep.c	2012-09-15 07:12:24 +0000
@@ -1447,27 +1447,21 @@
   action->sa_handler = handler;
   action->sa_flags = 0;
 #if defined (SA_RESTART)
-  /* Emacs mostly works better with restartable system services. If this
-     flag exists, we probably want to turn it on here.
-     However, on some systems (only hpux11 at present) this resets the
-     timeout of `select' which means that `select' never finishes if
-     it keeps getting signals.
-     We define BROKEN_SA_RESTART on those systems.  */
-  /* It's not clear why the comment above says "mostly works better".  --Stef
-     When SYNC_INPUT is set, we don't want SA_RESTART because we need to poll
+  /* SA_RESTART causes interruptible functions with timeouts (e.g.,
+     'select') to reset their timeout on some platforms (e.g.,
+     HP-UX 11), which is not what we want.  Also, when Emacs is
+     interactive, we don't want SA_RESTART because we need to poll
      for pending input so we need long-running syscalls to be interrupted
      after a signal that sets the interrupt_input_pending flag.  */
   /* Non-interactive keyboard input goes through stdio, where we always
      want restartable system calls.  */
-# if defined (BROKEN_SA_RESTART) || defined (SYNC_INPUT)
   if (noninteractive)
-# endif
     action->sa_flags = SA_RESTART;
 #endif
 }
 
 #ifdef FORWARD_SIGNAL_TO_MAIN_THREAD
-pthread_t main_thread;
+static pthread_t main_thread;
 #endif
 
 /* If we are on the main thread, handle the signal SIG with HANDLER.
@@ -1914,11 +1908,9 @@
 	{
 	  if (errno == EINTR)
 	    {
-#ifdef SYNC_INPUT
 	      /* I originally used `QUIT' but that might causes files to
 		 be truncated if you hit C-g in the middle of it.  --Stef  */
 	      process_pending_signals ();
-#endif
 	      continue;
 	    }
 	  else

=== modified file 'src/syssignal.h'
--- src/syssignal.h	2012-09-13 02:21:28 +0000
+++ src/syssignal.h	2012-09-15 06:57:23 +0000
@@ -64,8 +64,4 @@
 char *strsignal (int);
 #endif
 
-#ifdef FORWARD_SIGNAL_TO_MAIN_THREAD
-extern pthread_t main_thread;
-#endif
-
 void handle_on_main_thread (int, signal_handler_t);

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-09-15 07:06:56 +0000
+++ src/xdisp.c	2012-09-15 07:12:24 +0000
@@ -9290,12 +9290,6 @@
   struct gcpro gcpro1, gcpro2, gcpro3, gcpro4;
   USE_SAFE_ALLOCA;
 
-  /* Do nothing if called asynchronously.  Inserting text into
-     a buffer may call after-change-functions and alike and
-     that would means running Lisp asynchronously.  */
-  if (handling_signal)
-    return;
-
   fmt = msg = Qnil;
   GCPRO4 (fmt, msg, arg1, arg2);
 

=== modified file 'src/xterm.c'
--- src/xterm.c	2012-09-15 07:06:56 +0000
+++ src/xterm.c	2012-09-15 07:12:24 +0000
@@ -7129,25 +7129,17 @@
   if (interrupt_input_blocked)
     {
       interrupt_input_pending = 1;
-#ifdef SYNC_INPUT
       pending_signals = 1;
-#endif
       return -1;
     }
 
   interrupt_input_pending = 0;
-#ifdef SYNC_INPUT
   pending_signals = pending_atimers;
-#endif
   BLOCK_INPUT;
 
   /* So people can tell when we have read the available input.  */
   input_signal_count++;
 
-#ifndef SYNC_INPUT
-  ++handling_signal;
-#endif
-
   /* For debugging, this gives a way to fake an I/O error.  */
   if (terminal->display_info.x == XTread_socket_fake_io_error)
     {
@@ -7236,9 +7228,6 @@
       pending_autoraise_frame = 0;
     }
 
-#ifndef SYNC_INPUT
-  --handling_signal;
-#endif
   UNBLOCK_INPUT;
 
   return count;
@@ -7788,7 +7777,6 @@
 
   error_msg = alloca (strlen (error_message) + 1);
   strcpy (error_msg, error_message);
-  handling_signal = 0;
 
   /* Inhibit redisplay while frames are being deleted. */
   specbind (Qinhibit_redisplay, Qt);

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

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 00:54:49 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, Juanma Barranquero <lekktu@gmail.com>
> 
> When auditing signal-handling in preparation for cleaning it up, I
> found that configuring --without-sync-input has race conditions that
> look like they would be a real pain to fix.  Many of these involve
> memory allocation within a signal handler, which is tricky and
> dangerous.  Emacs attempts to work around the problems, but these
> workarounds are not sufficient and fixing them would not be easy.
> [...]
>  void *
>  xmalloc (size_t size)
>  {
> -  void *val;
> -
> -  MALLOC_BLOCK_INPUT;
> -  val = malloc (size);
> -  MALLOC_UNBLOCK_INPUT;
> -
> +  void *val = malloc (size);
>    if (!val && size)
>      memory_full (size);
>    return val;

Calling xmalloc was always safe to invoke from asynchronous entry into
the display engine, which happens, e.g., when mouse events are
processed.  Your patch removes that line of defense, which makes me
very nervous.  At the very least, let's have BLOCK_INPUT around the
call to malloc (and similarly in the other related functions).

> I see that nt/config.nt has "#undef SYNC_INPUT" but do the Microsoft
> ports care one way or another whether SYNC_INPUT is set?  If so, why?

I cannot answer that question, because the full semantics of
SYNC_INPUT is unclear to me.  All I can say now is that input events
on MS-Windows come from a separate thread that runs asynchronously to
the main thread (the latter runs the Lisp interpreter and all the
other parts of Emacs).  So, at least up front, Emacs on MS-Windows
does use non-SYNC_INPUT input method, if SYNC_INPUT is to be
understood literally.

OTOH, it could be that no one bothered or dared to define SYNC_INPUT
on MS-Windows when that method became the default on Posix platforms.
(The fact that config.nt undefines SYNC_INPUT is not indicative of
anything except that autogen/config.in does the same; the fact that
ms-w32.h does _not_ define SYNC_INPUT is the important detail.)

If someone can describe in detail what SYNC_INPUT means, what it
assumes of the target platform, and how is that reflected in the logic
of the related code, then I could try investigating the meaning of it
for the MS-Windows build.  As we no longer have on board people who
really understand the Emacs event handling on MS-Windows, such an
investigation will take a lot of time and effort, diverting my scarce
time from general-purpose Emacs development (such as menus on TTYs and
the remaining bits of bidi), and will necessarily be error-prone.  So
I'd really like to be sure there are very good reasons for removing
the non-SYNC_INPUT code.  It could be that a better alternative is to
leave that code alone, if only by replacing the conditionals with
WINDOWSNT or some such.

Btw, it looks like the NS port also uses the !SYNC_INPUT code; your
changes seem to remove that code without any substitute.

Btw2, your changes remove code conditioned on

  #if defined SYNC_INPUT || defined USABLE_SIGIO

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

> Since it's an undocumented and deprecated configure-time option, and
> has been that way for over four years, and the non-SYNC_INPUT code is
> a real mess that is getting in the way of improving Emacs, now seems
> like a good time to remove that code.

In what ways does the current SYNC_INPUT code get in the way of
improving Emacs, and what kinds of improvement will significantly
benefit from the proposed changes?  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 for us to leave it alone
and concentrate our energy on adding new user-level features.

Really, the latest push on non-trivial low-level changes seems to me
like a drain on our resources, with little real gains, except perhaps
on some obscure platforms I never heard about or in even more obscure
use-cases.  The only real effect of this is a significant
destabilization of the development codebase, which people already
starting to complain about.  I could understand such loss of stability
when the goal is a significant improvement in some important feature,
like GC or the display engine.  But having that for the sake of some
mythical "ease of improving Emacs" sounds like a net loss to me.  It
reminds me of the sorry state of roads in my country, which are
permanently in a state of being "maintained for future improvements",
causing closure of some of the lanes and generally making the traffic
more jammed than it needs to be.

In general, Emacs has long ago reached the state where low-level code
is stable and should be left alone, with most of the maintenance
effort directed towards adding user-level features.  Low-level code
changes should be considered only when there are very good reasons for
them.  Am I the only one who thinks so?

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

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

[Eli Zaretskii]

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

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

[Paul Eggert]

On 09/15/2012 04:03 AM, Eli Zaretskii wrote:

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

Yes.  We know where our signal handlers are, and we can audit them
to make sure they can't call non-async-signal-safe code.  And
that's the way Emacs has been running for years, on GNU and
POSIXish platforms: it has not been putting BLOCK_INPUT around
malloc calls.  On these platforms this patch is nothing new --
it's simply ratifying standard practice.  I'm not saying that the
SYNC_INPUT code is 100% bug-free -- it's not, and that's why I'm
auditing it -- but it's much, much better than the non-SYNC_INPUT
code is.

Out of curiosity, what happens in MS-Windows if you take the
current trunk and change nt/config.nt's "#undef SYNC_INPUT" to
"#define SYNC_INPUT 1"?  If that works, it would help simplify the
code overall.

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

First, we're using SYNC_INPUT already.  All non-Windows platform use
SYNC_INPUT, and have done so since 2008.

Second, we know that it's not safe to invoke random system
functions from signal handlers.  Emacs used to get away with this,
sort of, but the situation has gotten worse (i.e., flakier) with
time, partly due to the issue of multithreading.  So there are
sound software engineering reasons to go with SYNC_INPUT.  See,
for example, the brief discussion in <http://bugs.gnu.org/11080#16>.

> When is it not safe?

There is a small set of standard functions that signal handlers
can safely call.  Calling functions outside this list is unsafe
because it leads to race conditions.  Usually the unsafe functions
work, but sometimes they don't, and bugs are hard to track down
and fix.

The exact list of safe functions depends on the platform.
For OpenBSD, for example, there's a list in
<http://www.openbsd.org/cgi-bin/man.cgi?query=signal>.
POSIX has a standard list in
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03>.

Code that limits itself to the POSIX list should be safe in
practice.  Emacs probably needs to go beyond the POSIX list, on a
platform-by-platform basis, but it needs to take some care when
doing so.

> what is this about:
> 
>> -#ifdef REL_ALLOC
>> -  malloc_hysteresis = 32;
>> -#else
>> -  malloc_hysteresis = 0;
>> -#endif

malloc_hysteresis is used only by the non-SYNC_INPUT code.
Removing the non-SYNC_INPUT code lets us remove cruft that is
needed only because of the non-SYNC_INPUT code.

> I never have such problems on MS-Windows

I don't use MS-Windows.  Apparently our experiences on GNU/Linux
differ.  I expect that I am a heavier use of that platform and so
am more likely to run into Emacs bugs there.

I'm not the only one to think that the non-SYNC_INPUT code is
questionable -- it's been a longstanding issue.  Since the
MS-Windows port does not exercise the interrupt-based input
handling defined by the non-SYNC_INPUT code, that could well
explain why you're not observing problems with MS-Windows.  And
this would also suggest that the MS-Windows code does not care
whether SYNC_INPUT is used, so it can also profitably change to
use SYNC_INPUT.

> With the kind of high rate of changes we see in Emacs,

I've been seeing problems for years.  It's not due to any recent changes.

> If it works well,

The non-SYNC_INPUT code doesn't work well at all.  The SYNC_INPUT
code is better, but it can still use an audit, which I'm doing.

> whoever wants to make non-trivial changes in that code _must_
> understand it very well.

I understand the non-Microsoft side well, and from that point of
view this change is a good one, because it removes unused and
confusing code that complicates the job of Emacs maintenance.  I
do not understand the Microsoft side, but that should be a
separate issue.

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

Yes, and there's non-HAVE_NS code in there too.  But that's not
relevant.  The point is that SYNC_INPUT is always 1 for the NextStep
port, just as it's always 1 for all ports other than MS-Windows.

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

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 12:59:44 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12450@debbugs.gnu.org, lekktu@gmail.com
> 
> Out of curiosity, what happens in MS-Windows if you take the
> current trunk and change nt/config.nt's "#undef SYNC_INPUT" to
> "#define SYNC_INPUT 1"?  If that works, it would help simplify the
> code overall.

I tried your patches already, they compile, and the resulting binary
seems to work.  But what does that prove?  Should I remind you that
another change installed recently took several days to reveal?

I hope Stefan will be able to add some real information to this issue.

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

[Paul Eggert]

On 09/15/2012 01:15 PM, Eli Zaretskii wrote:
> I tried your patches already, they compile, and the resulting binary
> seems to work.

Excellent!  Thanks for trying it out.

> what does that prove?

It doesn't *prove* anything -- there are no *proofs* of any
nontrivial Emacs code, to my knowledge -- but it's a good indication
that this change is benign for the Microsoft port.  That is what I'd
expect from my admittedly-limited understanding of the Microsoft port,
for reasons already discussed.

The change is a real win for the mainline code, so this is
a good sign.  Thanks again for checking it.

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

[Stefan Monnier]

>> If someone can describe in detail what SYNC_INPUT means

Maybe not quite, because it was implemented rather than designed.
But SYNC_INPUT's purpose is to reduce the code run during POSIX's signal
handling to its minimum (since it's basically unsafe to do anything in
there, due to POSIX's definition of signal handling), so it only sets
a global var (pending_signals) which is then polled by QUIT, so that the
real code reacting to the arrival of a signal is run synchronously.

This avoids problems such as malloc being called in the middle of
another malloc invocation.

The downside of SYNC_INPUT is that we may fail to poll pending_signals
often enough and hence become unresponsive.  Since SYNC_INPUT has been
the default for a long while now, I think we can drop the non-SYNC_INPUT
case, indeed, as suggested by Paul.  But I don't know how it interacts
with the non-X11 code.


        Stefan

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

[Richard Stallman]

I have a vague memory that the sync input code had an important flaw
-- that for certain display-updating tasks (perhaps
mouse-highlighting) it could cause a delay until Emacs was read to
accept input, which the other code could do instantly.

I don't know if this is true now, and I'm not sure of the memory at all.
But it would be good to investigate this question.
Maybe there is a way to fix the problem.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Paul Eggert]

On 09/15/2012 03:18 PM, Richard Stallman wrote:
> I have a vague memory that the sync input code had an important flaw
> -- that for certain display-updating tasks (perhaps
> mouse-highlighting) it could cause a delay until Emacs was read to
> accept input, which the other code could do instantly.
> 
> I don't know if this is true now, and I'm not sure of the memory at all.
> But it would be good to investigate this question.

Yes, that topic came up in 2008 when SYNC_INPUT was made the
default on non-Windows hosts.  That discussion concluded that it's
not a problem in practice, because SYNC_INPUT does not postpone
X11 event processing indefinitely; it postpones it only until the
next QUIT or UNBLOCK_INPUT.  Please see Stefan's comment in
<http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01368.html>,
along with the surrounding thread.  The remaining issues noted in
that thread all seem to have been fixed since then, for the
SYNC_INPUT case.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  lekktu@gmail.com,  12450@debbugs.gnu.org
> Date: Sat, 15 Sep 2012 17:12:13 -0400
> 
> >> If someone can describe in detail what SYNC_INPUT means
> 
> Maybe not quite, because it was implemented rather than designed.
> But SYNC_INPUT's purpose is to reduce the code run during POSIX's signal
> handling to its minimum (since it's basically unsafe to do anything in
> there, due to POSIX's definition of signal handling), so it only sets
> a global var (pending_signals) which is then polled by QUIT, so that the
> real code reacting to the arrival of a signal is run synchronously.
> 
> This avoids problems such as malloc being called in the middle of
> another malloc invocation.
> 
> The downside of SYNC_INPUT is that we may fail to poll pending_signals
> often enough and hence become unresponsive.  Since SYNC_INPUT has been
> the default for a long while now, I think we can drop the non-SYNC_INPUT
> case, indeed, as suggested by Paul.  But I don't know how it interacts
> with the non-X11 code.

Could you please describe how the SYNC_INPUT code is supposed to work
in the following situations:

  . keyboard input on a TTY that comes while Lisp is running

  . an X event that exposes an Emacs frame in a GUI session, coming
    while Lisp is running

Thanks.

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

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 20:15:36 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: lekktu@gmail.com, 12450@debbugs.gnu.org
> 
> On 09/15/2012 03:18 PM, Richard Stallman wrote:
> > I have a vague memory that the sync input code had an important flaw
> > -- that for certain display-updating tasks (perhaps
> > mouse-highlighting) it could cause a delay until Emacs was read to
> > accept input, which the other code could do instantly.
> > 
> > I don't know if this is true now, and I'm not sure of the memory at all.
> > But it would be good to investigate this question.
> 
> Yes, that topic came up in 2008 when SYNC_INPUT was made the
> default on non-Windows hosts.  That discussion concluded that it's
> not a problem in practice, because SYNC_INPUT does not postpone
> X11 event processing indefinitely; it postpones it only until the
> next QUIT or UNBLOCK_INPUT.  Please see Stefan's comment in
> <http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01368.html>,
> along with the surrounding thread.  The remaining issues noted in
> that thread all seem to have been fixed since then, for the
> SYNC_INPUT case.

That thread left the MS-Windows case indeterminate.

And I still would like to have BLOCK_INPUT in xmalloc and friends,
conditioned on some global variable being non-zero.  That way, if some
strange problems come up, we can ask people to set that variable to a
non-zero value in a debugger and see if the problems persist.  Given
that no one here actually understands all the aspects of the related
issues, that is a prudent thing to do, especially with code freeze and
Emacs 24.3 release looming.

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

[Eli Zaretskii]

> Date: Sat, 15 Sep 2012 12:59:44 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12450@debbugs.gnu.org, lekktu@gmail.com
> 
> >> -#ifdef REL_ALLOC
> >> -  malloc_hysteresis = 32;
> >> -#else
> >> -  malloc_hysteresis = 0;
> >> -#endif
> 
> malloc_hysteresis is used only by the non-SYNC_INPUT code.

No, it is also used indirectly, via __malloc_extra_blocks, in
gmalloc.c and in ralloc.c.  Since only one platform I know of that
uses SYNC_INPUT also uses ralloc.c, I'm not sure it's safe to make
this change to __malloc_extra_blocks.

But there's something I don't understand about this snippet.  Why does
it set the value to 32 conditioned by REL_ALLOC, and just a few days
after the change which introduced this snippet (18 years ago) there
was a change committed in ralloc.c that overrides the value of
__malloc_extra_blocks with 64?  If using ralloc.c always sets
__malloc_extra_blocks to 64, why setting it to 32 in alloc.c is
conditioned by REL_ALLOC?

Richard, you made both changes -- can you perhaps shed some light on
this?

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

[Paul Eggert]

On 09/15/2012 11:33 PM, Eli Zaretskii wrote:
>>>> -#ifdef REL_ALLOC
>>>> > >> -  malloc_hysteresis = 32;
>>>> > >> -#else
>>>> > >> -  malloc_hysteresis = 0;
>>>> > >> -#endif
>> > 
>> > malloc_hysteresis is used only by the non-SYNC_INPUT code.
> No, it is also used indirectly, via __malloc_extra_blocks, in
> gmalloc.c and in ralloc.c.

No, it is not used indirectly.  emacs_blocked_malloc is the only
function that uses malloc_hysteresis to set __malloc_extra_blocks.
And emacs_blocked_malloc is invoked only in the non-SYNC_INPUT code.

> But there's something I don't understand about this snippet.  Why does
> it set the value to 32 conditioned by REL_ALLOC ...

A nice property of removing the non-SYNC_INPUT code is that
we don't need to worry about cruft like that, because it's
not being used and we can remove it.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 00:47:57 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Richard Stallman <rms@gnu.org>, 12450@debbugs.gnu.org, 
>  lekktu@gmail.com
> 
> On 09/15/2012 11:33 PM, Eli Zaretskii wrote:
> >>>> -#ifdef REL_ALLOC
> >>>> > >> -  malloc_hysteresis = 32;
> >>>> > >> -#else
> >>>> > >> -  malloc_hysteresis = 0;
> >>>> > >> -#endif
> >> > 
> >> > malloc_hysteresis is used only by the non-SYNC_INPUT code.
> > No, it is also used indirectly, via __malloc_extra_blocks, in
> > gmalloc.c and in ralloc.c.
> 
> No, it is not used indirectly.  emacs_blocked_malloc is the only
> function that uses malloc_hysteresis to set __malloc_extra_blocks.
> And emacs_blocked_malloc is invoked only in the non-SYNC_INPUT code.

Which means that gmalloc.c, and any memory allocation based on that,
will work differently with that function removed, unless we keep
__malloc_extra_blocks at its present value.  The amount of extra
blocks reserved by gmalloc has nothing to do with emacs_blocked_malloc
(or at least no one came up with explanation why it does).  In the
absence of such an explanation, you are suggesting to remove code
whose effect on platforms that use gmalloc is not fully understood.

> > But there's something I don't understand about this snippet.  Why does
> > it set the value to 32 conditioned by REL_ALLOC ...
> 
> A nice property of removing the non-SYNC_INPUT code is that
> we don't need to worry about cruft like that, because it's
> not being used and we can remove it.

If we don't understand that "cruft", how can we claim in good faith
it's cruft, and how can we remove or modify it in non-trivial ways and
still claim with straight face that we are making Emacs more stable
and reliable?

Perhaps you don't care about platforms that use gmalloc.  Otherwise, I
don't understand your line of thinking at all.

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

[Paul Eggert]

On 09/16/2012 01:05 AM, Eli Zaretskii wrote:

>> No, it is not used indirectly.  emacs_blocked_malloc is the only
>> function that uses malloc_hysteresis to set __malloc_extra_blocks.
>> And emacs_blocked_malloc is invoked only in the non-SYNC_INPUT code.
> 
> Which means that gmalloc.c, and any memory allocation based on that,
> will work differently with that function removed

No, because the function is never invoked, if we assume SYNC_INPUT.
Since it's never invoked, gmalloc.c's behavior cannot possibly change
if we remove it.

> Perhaps you don't care about platforms that use gmalloc.

No, the argument is independent of whether the platform uses gmalloc.
The point is that we can remove code that's never invoked,
and we can remove all variables that are used only by that code.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 01:17:33 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, 12450@debbugs.gnu.org, lekktu@gmail.com
> 
> On 09/16/2012 01:05 AM, Eli Zaretskii wrote:
> 
> >> No, it is not used indirectly.  emacs_blocked_malloc is the only
> >> function that uses malloc_hysteresis to set __malloc_extra_blocks.
> >> And emacs_blocked_malloc is invoked only in the non-SYNC_INPUT code.
> > 
> > Which means that gmalloc.c, and any memory allocation based on that,
> > will work differently with that function removed
> 
> No, because the function is never invoked, if we assume SYNC_INPUT.

Yes, it _is_ invoked on platforms that don't use SYNC_INPUT now.

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

[Paul Eggert]

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.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 01:17:33 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, 12450@debbugs.gnu.org, lekktu@gmail.com
> 
> On 09/16/2012 01:05 AM, Eli Zaretskii wrote:
> 
> >> No, it is not used indirectly.  emacs_blocked_malloc is the only
> >> function that uses malloc_hysteresis to set __malloc_extra_blocks.
> >> And emacs_blocked_malloc is invoked only in the non-SYNC_INPUT code.
> > 
> > Which means that gmalloc.c, and any memory allocation based on that,
> > will work differently with that function removed
> 
> No, because the function is never invoked, if we assume SYNC_INPUT.

Yes, it _is_ invoked on platforms that don't use SYNC_INPUT now.

And in addition, we cannot be sure whether its non-invocation on
SYNC_INPUT platforms isn't a simple omission, because most Posix
platforms use neither gmalloc nor ralloc.c.  So, when SYNC_INPUT was
coded, it's quite possible that assignment to __malloc_extra_blocks
was omitted by mistake that never got revealed.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 01:23:28 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, lekktu@gmail.com, 12450@debbugs.gnu.org
> 
> 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.

Nevertheless, please humor me.

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

All I meant to say is that the jury is still out on this issue.  That
we don't know any better now does not settle the issue in any way.  A
few minutes of my running with SYNC_INPUT aren't a convincing
evidence, either.  So please don't try to make this look as a
non-issue; only the future will tell.

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

[Paul Eggert]

On 09/16/2012 01:24 AM, Eli Zaretskii wrote:
> Yes, it _is_ invoked on platforms that don't use SYNC_INPUT now.

But the point of the patch is to assume SYNC_INPUT.

> we cannot be sure whether its non-invocation on
> SYNC_INPUT platforms isn't a simple omission, because most Posix
> platforms use neither gmalloc nor ralloc.c.

I'm not sure how you're counting, but many POSIXish systems use gmalloc.
These include FreeBSD, NetBSD, OpenBSD, HP-UX, AIX, and IRIX.

Of course it's possible that there are memory allocation glitches
on such systems, glitches that we haven't caught in the four years we've
been using SYNC_INPUT.  But any such glitches would be an independent
bug, i.e., a bug that we should fix independently of whether we remove
--without-sync-input.  And the glitches can't be that serious,
or we'd have noticed them before now.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 01:34:52 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, 12450@debbugs.gnu.org, lekktu@gmail.com
> 
> > we cannot be sure whether its non-invocation on
> > SYNC_INPUT platforms isn't a simple omission, because most Posix
> > platforms use neither gmalloc nor ralloc.c.
> 
> I'm not sure how you're counting, but many POSIXish systems use gmalloc.
> These include FreeBSD, NetBSD, OpenBSD, HP-UX, AIX, and IRIX.

Most people here use GNU/Linux, which doesn't.  I don't know what
Stefan used to test SYNC_INPUT.

> Of course it's possible that there are memory allocation glitches
> on such systems, glitches that we haven't caught in the four years we've
> been using SYNC_INPUT.  But any such glitches would be an independent
> bug, i.e., a bug that we should fix independently of whether we remove
> --without-sync-input.

I'm not talking about removing the option, I'm talking about what
should and shouldn't be done as part of that removal.  You suggest
removing some part whose significance we do not understand in full.
We can either dig into the related code and our memories and
understand those parts, or we can play it safe and not remove the
parts we don't understand.  Any third possibility would be acting
irresponsibly on our part.

> And the glitches can't be that serious, or we'd have noticed them
> before now.

See bug #12242, for a demonstration of how easy to notice such bugs.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On 9/15/12 2:32 AM, Eli Zaretskii wrote:
> In what ways does the current SYNC_INPUT code get in the way of
> improving Emacs, and what kinds of improvement will significantly
> benefit from the proposed changes?

> It reminds me of the sorry state of roads in my country, which are 
> permanently in a state of being "maintained for future
> improvements", causing closure of some of the lanes and generally
> making the traffic more jammed than it needs to be.

Working on the the Emacs core is like doing road work in an old city
filled with catacombs, unmapped utility lines, and ancient Roman
sewers under the streets. Work is slow and fraught become nobody
really understands what's going on, and nobody really understands
what's going on because nobody works on it.

Paul's doing a great job reducing a lot of the low-level complication
in the code. In particular, his work would have simplified my patches
yet-unmerged for launching children via posix_spawn and having Emacs
not poll every few seconds while blocked and waiting for input. Both
are good user-level features.

> As we no longer have on board people who
> really understand the Emacs event handling
> on MS-Windows, such an investigation will
> take a lot of time and effort

I've done some work on that code for my cygw32 patchset, an updated
version of which I'll post shortly (as soon as I sit down and write
the myriad Changelog entries I need).

The MS-Windows support in Emacs, by the way, is a microcosm of the
problem I mentioned above. We really need to stop support for Windows
9x and non-UNICODE systems if we're to simplify the code enough to fix
nagging problems, like persistent flickering on tooltip updates. I'm
also much less motivated to add features (like rich copy-and-paste
support) when I have to go dig up Windows 95 documentation and
translate it from the ancient Sumerian in order to figure out whether
the code I'm writing might break when the Museum of Computing tries to
run a modern Emacs on one of its exhibits.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 02:33:45 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: Paul Eggert <eggert@cs.ucla.edu>, lekktu@gmail.com, 
>  12450@debbugs.gnu.org
> 
> Working on the the Emacs core is like doing road work in an old city
> filled with catacombs, unmapped utility lines, and ancient Roman
> sewers under the streets. Work is slow and fraught become nobody
> really understands what's going on, and nobody really understands
> what's going on because nobody works on it.

That's an exaggeration.  Just a year ago I finished working on a major
change in the display engine.  I do understand the code I changed.

I'm quite sure that Stefan has similar, if not better, understanding
of the parts he changed to introduce lexical binding.

> Paul's doing a great job reducing a lot of the low-level complication
> in the code.

I agree.  But where the code we change is not understood well, let
alone related to platforms Paul doesn't use and doesn't care about,
peer review and commentary are in order.  I see nothing in this
process that is extraordinary; do you?

> In particular, his work would have simplified my patches
> yet-unmerged for launching children via posix_spawn and having Emacs
> not poll every few seconds while blocked and waiting for input. Both
> are good user-level features.

That's good to hear.  However, simplification of the code is not a
goal in itself.  The simplified code should be correct, first and
foremost.  That is what this discussion is about, at least as far as
I'm concerned

> The MS-Windows support in Emacs, by the way, is a microcosm of the
> problem I mentioned above. We really need to stop support for Windows
> 9x and non-UNICODE systems if we're to simplify the code enough to fix
> nagging problems, like persistent flickering on tooltip updates.

I don't see any relation between non-Unicode APIs and flickering.  If
you can explain how they are related, please do.

> I'm
> also much less motivated to add features (like rich copy-and-paste
> support) when I have to go dig up Windows 95 documentation and
> translate it from the ancient Sumerian in order to figure out whether
> the code I'm writing might break when the Museum of Computing tries to
> run a modern Emacs on one of its exhibits.

I already suggested a way of dealing with that: introduce new features
conditioned on a run-time test of a variable, which will only be
non-zero on the latest versions of Windows.  There's no requirement to
have every new feature work on Windows 9X; the only requirement is to
try not to break existing features that already work there (and even
that requirement is not non-negotiable).

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 02:52:35 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: Eli Zaretskii <eliz@gnu.org>, lekktu@gmail.com, rms@gnu.org, 
>  12450@debbugs.gnu.org
> 
> > 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.

That's good to know, thanks.

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

Please tell the details about this.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On 9/16/12 3:44 AM, Eli Zaretskii wrote:
>> 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.
> 
> Please tell the details about this.
> 

I'm still not sure what practical effect this omission would have ---
on quit, we set Vquit_flag to Qt from the input thread. When Lisp code
is running, QUIT picks up the non-nilness of Vquit_flag and quits. The
ELSE_PENDING_SIGNALS branch doesn't apply, so we're able to
successfully quit.

While testing, I ran into a different bug. I'm able to reproduce it on
the regular w32 build too. Can someone try reproing it with 1) M-:
(while t) RET, 2) click the menu bar [menu won't appear], 3) C-g, 4)
typing something? Emacs doesn't seem to respond to typed input.
Clicking in the Emacs window unblocks everything.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

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

[Stefan Monnier]

> Could you please describe how the SYNC_INPUT code is supposed to work
> in the following situations:
>   . keyboard input on a TTY that comes while Lisp is running
>   . an X event that exposes an Emacs frame in a GUI session, coming
>     while Lisp is running

- The keyboard input or the X event causes a signal to be delivered.
- The signal handler sets pending_signal and returns.
- The Elisp interpreter ends up calling QUIT sooon afterwards.
- QUIT processes the pending signals which will read the (keyboard/X11)
  input and turn it in an event in the event queue (so input-pending-p
  will know something has arrived), it may also do some more processing
  such as redraw the window if the GUI needs it.  Currently it also
  handles things like mouse-face highlighting.
- The Elisp interpreter then keeps running the code it was running, as
  if nothing happened.

So SYNC_INPUT basically delays the processing of incoming signals from
"run it at any time" to "run it at the next safe point" where a safe
point is defined as "a point where we call QUIT".  "QUIT" can also be
understood as a sibling of "yield".

Does that answer your question?


        Stefan

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

[Stefan Monnier]

> That's an exaggeration.  Just a year ago I finished working on a major
> change in the display engine.  I do understand the code I changed.
> I'm quite sure that Stefan has similar, if not better, understanding
> of the parts he changed to introduce lexical binding.

[ BTW, let's not forget that most of the lexical-binding code was
  written by Miles.  ]
An important difference is that the code involved in lexical-binding
(or in the buffer-local bindings which I rewrote around the same time)
is platform independent.  So it does not depend on trying to imagine
what might happen on this and that long-forgotten system which used some
particular unusual combination of CPP flags.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Daniel Colascione <dancol@dancol.org>,  lekktu@gmail.com,  eggert@cs.ucla.edu,  12450@debbugs.gnu.org
> Date: Sun, 16 Sep 2012 11:10:30 -0400
> 
> > That's an exaggeration.  Just a year ago I finished working on a major
> > change in the display engine.  I do understand the code I changed.
> > I'm quite sure that Stefan has similar, if not better, understanding
> > of the parts he changed to introduce lexical binding.
> 
> [ BTW, let's not forget that most of the lexical-binding code was
>   written by Miles.  ]

Sorry about that, my bad.

> An important difference is that the code involved in lexical-binding
> (or in the buffer-local bindings which I rewrote around the same time)
> is platform independent.

So is most of the display code I modified.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eggert@cs.ucla.edu,  lekktu@gmail.com,  12450@debbugs.gnu.org
> Date: Sun, 16 Sep 2012 10:58:41 -0400
> 
> > Could you please describe how the SYNC_INPUT code is supposed to work
> > in the following situations:
> >   . keyboard input on a TTY that comes while Lisp is running
> >   . an X event that exposes an Emacs frame in a GUI session, coming
> >     while Lisp is running
> 
> - The keyboard input or the X event causes a signal to be delivered.

Which signals are those, specifically?

> - QUIT processes the pending signals which will read the (keyboard/X11)
>   input and turn it in an event in the event queue (so input-pending-p
>   will know something has arrived), it may also do some more processing
>   such as redraw the window if the GUI needs it.  Currently it also
>   handles things like mouse-face highlighting.

Perhaps you could update the relevant portions in the commentary at
the beginning of xdisp.c, as they tell a somewhat different story
(probably about a soon-to-become-extinct non-SYNC_INPUT mode).

> So SYNC_INPUT basically delays the processing of incoming signals from
> "run it at any time" to "run it at the next safe point" where a safe
> point is defined as "a point where we call QUIT".  "QUIT" can also be
> understood as a sibling of "yield".
> 
> Does that answer your question?

It's a beginning, thanks.

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

[Paul Eggert]

On 09/16/2012 08:45 AM, Eli Zaretskii wrote:
>> - The keyboard input or the X event causes a signal to be delivered.
> Which signals are those, specifically?

SIGWINCH for window changes.

SIGIO, SIGINT and SIGQUIT for keyboard input, if interactive.
But SIGIO is not used on platforms where it doesn't work.
And SIGQUIT is not caught on DOS_NT.

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

[Stefan Monnier]

>> > Could you please describe how the SYNC_INPUT code is supposed to work
>> > in the following situations:
>> >   . keyboard input on a TTY that comes while Lisp is running
>> >   . an X event that exposes an Emacs frame in a GUI session, coming
>> >     while Lisp is running
>> - The keyboard input or the X event causes a signal to be delivered.
> Which signals are those, specifically?

I'm not familiar enough to be sure (I changed the code of the signal
handler, but not the code that sets it up), but I think it's SIGIO
(basically, both the tty and the X11 code end up having
a file-descriptor on which inputs arrive, and the code sets up this
file-descriptor so that the kernel sends us a signal when input is
ready).

>> - QUIT processes the pending signals which will read the (keyboard/X11)
>> input and turn it in an event in the event queue (so input-pending-p
>> will know something has arrived), it may also do some more processing
>> such as redraw the window if the GUI needs it.  Currently it also
>> handles things like mouse-face highlighting.
> Perhaps you could update the relevant portions in the commentary at
> the beginning of xdisp.c, as they tell a somewhat different story
> (probably about a soon-to-become-extinct non-SYNC_INPUT mode).

I'll try and take a look, thanks.


        Stefan

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 09:30:27 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, lekktu@gmail.com, 
>  12450@debbugs.gnu.org
> 
> On 09/16/2012 08:45 AM, Eli Zaretskii wrote:
> >> - The keyboard input or the X event causes a signal to be delivered.
> > Which signals are those, specifically?
> 
> SIGWINCH for window changes.
> 
> SIGIO, SIGINT and SIGQUIT for keyboard input, if interactive.
> But SIGIO is not used on platforms where it doesn't work.

Thanks, but what about X input events?

> And SIGQUIT is not caught on DOS_NT.

Because there's no SIGQUIT on Windows.  (And on DOS, keyboard
interrupts are disabled at startup, with the exception of Ctrl-BREAK.)

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

[Jan Djärv]

16 sep 2012 kl. 20:40 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Sun, 16 Sep 2012 09:30:27 -0700
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> CC: Stefan Monnier <monnier@iro.umontreal.ca>, lekktu@gmail.com, 
>> 12450@debbugs.gnu.org
>> 
>> On 09/16/2012 08:45 AM, Eli Zaretskii wrote:
>>>> - The keyboard input or the X event causes a signal to be delivered.
>>> Which signals are those, specifically?
>> 
>> SIGWINCH for window changes.
>> 
>> SIGIO, SIGINT and SIGQUIT for keyboard input, if interactive.
>> But SIGIO is not used on platforms where it doesn't work.
> 
> Thanks, but what about X input events?

SIGIO.

	Jan D.

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

[Paul Eggert]

On 09/16/2012 01:32 AM, Eli Zaretskii wrote:

> Nevertheless, please humor me.

OK, I installed a version that does that, by keeping all
the calls to MALLOC_BLOCK_INPUT and MALLOC_UNBLOCK_INPUT,
but defining those macros in a different way based on a new
macro XMALLOC_BLOCK_INPUT_CHECK rather than on the
(now-obsolete) SYNC_INPUT.

I also looked into that hysteresis thing, and the code
in question was redundant because r_alloc_init assigns
64 to __malloc_extra_blocks.  So we should be OK there.

Since the patch is installed now I'm marking this bug as done.
If bugs crop up we can reopen it or open a new bug report.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 03:56:20 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: eggert@cs.ucla.edu, lekktu@gmail.com, rms@gnu.org, 
>  12450@debbugs.gnu.org
> 
> >> 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.
> > 
> > Please tell the details about this.
> > 
> 
> I'm still not sure what practical effect this omission would have ---
> on quit, we set Vquit_flag to Qt from the input thread. When Lisp code
> is running, QUIT picks up the non-nilness of Vquit_flag and quits. The
> ELSE_PENDING_SIGNALS branch doesn't apply, so we're able to
> successfully quit.

I added setting pending_signals, it doesn't seem to do any harm, and
playing by the rules has its merit.

> While testing, I ran into a different bug. I'm able to reproduce it on
> the regular w32 build too. Can someone try reproing it with 1) M-:
> (while t) RET, 2) click the menu bar [menu won't appear], 3) C-g, 4)
> typing something? Emacs doesn't seem to respond to typed input.
> Clicking in the Emacs window unblocks everything.

Yes, I see this also.  There's a long comment about this in w32fns.c
around line 2550.  I'm not sure if there's a way to unlock responses
to keyboard input in this scenario; ideas welcome.

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

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 14:48:55 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rms@gnu.org, lekktu@gmail.com, 12450-done@debbugs.gnu.org
> 
> Since the patch is installed now I'm marking this bug as done.
> If bugs crop up we can reopen it or open a new bug report.

There are still a lot of comments in the code that describe the
non-SYNC_INPUT mode.  For example, see blockinput.h.

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

[Paul Eggert]

On 09/17/2012 12:42 AM, Eli Zaretskii wrote:

> There are still a lot of comments in the code that describe the
> non-SYNC_INPUT mode.  For example, see blockinput.h.

Thanks, I've fixed up the blockinput.h comments in the proposed patch
for Bug#12471; please see <http://bugs.gnu.org/12471#20>.  Any other
comments need fixing, please feel free to let me know.

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

[Eli Zaretskii]

> Date: Fri, 21 Sep 2012 13:50:45 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12450@debbugs.gnu.org
> 
> On 09/17/2012 12:42 AM, Eli Zaretskii wrote:
> 
> > There are still a lot of comments in the code that describe the
> > non-SYNC_INPUT mode.  For example, see blockinput.h.
> 
> Thanks, I've fixed up the blockinput.h comments in the proposed patch
> for Bug#12471; please see <http://bugs.gnu.org/12471#20>.  Any other
> comments need fixing, please feel free to let me know.

Here are a few suspects:

termopts.h:

  /* Nonzero means use interrupt-driven input.  */
  extern int interrupt_input;

  /* Nonzero while interrupts are temporarily deferred during redisplay.  */
  extern int interrupts_deferred;

xdisp.c:

              /* Redisplay that happens asynchronously due to an expose event
                 may access f->tool_bar_items.  Make sure we update both
                 variables within BLOCK_INPUT so no such event interrupts.  */

  /* Redraw the part of window W intersection rectangle FR.  Pixel
     coordinates in FR are frame-relative.  Call this function with
     input blocked.  Value is non-zero if the exposure overwrites
     mouse-face.  */

   This function may only use code that doesn't eval because it is
   called asynchronously from note_mouse_highlight.  */

  /* This function can be called asynchronously, which means we must
     exclude any possibility that Fget_text_property signals an
     error.  */

   This is an ugly monster macro construct because we must use alloca
   to allocate glyph strings (because draw_glyphs can be called
   asynchronously).  */

		  /* Prevent various kinds of signals during display
		     update.  stdio is not robust about handling
		     signals, which can cause an apparent I/O
		     error.  */

dispnew.c:

         On the other hand, we need notice_overwritten_cursor as long
         as mouse highlighting is done asynchronously outside of
         redisplay.  */

   If DELAY, assume we're being called from a signal handler, and
   queue the change for later - perhaps the next redisplay.
   Since this tries to resize windows, we can't call it
   from a signal handler.

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

[Paul Eggert]

On 09/22/2012 02:03 AM, Eli Zaretskii wrote:
> Here are a few suspects:

Thanks, those comments mostly look OK, so far as it goes.
When they use the word "asynchronously", I assume
they're talking about from the Lisp point of view,
not the Unix signal-handler point of view.  A possible
exception is that comment about alloca and glyph strings
and I'll try to add that to my list of things to look at.

Some calls to BLOCK_INPUT can be removed (there's a FIXME
about this) and when they do the corresponding commentary
needs to be updated; that probably includes some of the
comments you mention.  This is also on my list of things to
look at.

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

[Eli Zaretskii]

> Date: Sat, 22 Sep 2012 02:34:58 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12450@debbugs.gnu.org
> 
> When they use the word "asynchronously", I assume
> they're talking about from the Lisp point of view,
> not the Unix signal-handler point of view.

The comments in redisplay code don't talk about Lisp.  There's no Lisp
running when redisplay happens, except through safe_eval.  These
comments talk about asynchronous entry to redisplay mentioned in the
large commentary near the beginning of xdisp.c.  AFAIU, this
asynchronous entry is no longer possible.

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

[Paul Eggert]

On 09/22/2012 02:50 AM, Eli Zaretskii wrote:
> These
> comments talk about asynchronous entry to redisplay mentioned in the
> large commentary near the beginning of xdisp.c.  AFAIU, this
> asynchronous entry is no longer possible.

Yes, thanks, that sounds right, so I'll also add updating
those comments to my list of things to do.