Package: emacs;
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sat, 15 Sep 2012 07:57:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12450 in the body.
You can then email your comments to 12450 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 07:57:02 GMT) Full text and rfc822 format available.Paul Eggert <eggert <at> cs.ucla.edu>
:bug-gnu-emacs <at> gnu.org
.
(Sat, 15 Sep 2012 07:57:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: bug-gnu-emacs <at> gnu.org Cc: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Subject: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 00:54:49 -0700
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 <at> 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 <at> cs.ucla.edu> + + Remove configure's --without-sync-input option. + * CPP-DEFINES (BROKEN_SA_RESTART, SA_RESTART): Remove. + 2012-09-13 Paul Eggert <eggert <at> 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 <at> 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 <at> 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 <at> 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; -} - - -#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 */ - +} /*********************************************************************** @@ -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; } -#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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 09:34:02 GMT) Full text and rfc822 format available.Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, bug-gnu-emacs <at> gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 12:32:15 +0300
> Date: Sat, 15 Sep 2012 00:54:49 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: Eli Zaretskii <eliz <at> gnu.org>, Juanma Barranquero <lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 10:16:01 GMT) Full text and rfc822 format available.Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, bug-gnu-emacs <at> gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 03:14:50 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 11:17:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, bug-gnu-emacs <at> gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 14:03:22 +0300
> Date: Sat, 15 Sep 2012 03:14:50 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: bug-gnu-emacs <at> gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 20:01:02 GMT) Full text and rfc822 format available.Message #17 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 12:59:44 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 20:17:01 GMT) Full text and rfc822 format available.Message #20 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 23:15:41 +0300
> Date: Sat, 15 Sep 2012 12:59:44 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: 12450 <at> debbugs.gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 20:33:01 GMT) Full text and rfc822 format available.Message #23 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 13:31:12 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 21:14:02 GMT) Full text and rfc822 format available.Message #26 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Monnier <monnier <at> iro.umontreal.ca> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. 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. Stefan
bug-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 15 Sep 2012 22:21:01 GMT) Full text and rfc822 format available.Message #29 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Richard Stallman <rms <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 18:18:59 -0400
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 03:17:01 GMT) Full text and rfc822 format available.Message #32 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: rms <at> gnu.org Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 15 Sep 2012 20:15:36 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 05:57:01 GMT) Full text and rfc822 format available.Message #35 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 08:55:14 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca> > Cc: Eli Zaretskii <eliz <at> gnu.org>, lekktu <at> gmail.com, 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 06:12:02 GMT) Full text and rfc822 format available.Message #38 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 09:10:15 +0300
> Date: Sat, 15 Sep 2012 20:15:36 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > Cc: lekktu <at> gmail.com, 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 06:35:01 GMT) Full text and rfc822 format available.Message #41 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu>, Richard Stallman <rms <at> gnu.org> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 09:33:02 +0300
> Date: Sat, 15 Sep 2012 12:59:44 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: 12450 <at> debbugs.gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 07:50:02 GMT) Full text and rfc822 format available.Message #44 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, Richard Stallman <rms <at> gnu.org>, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 00:47:57 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:08:01 GMT) Full text and rfc822 format available.Message #47 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 11:05:55 +0300
> Date: Sun, 16 Sep 2012 00:47:57 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: Richard Stallman <rms <at> gnu.org>, 12450 <at> debbugs.gnu.org, > lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:19:01 GMT) Full text and rfc822 format available.Message #50 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 01:17:33 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:24:01 GMT) Full text and rfc822 format available.Message #53 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 11:21:35 +0300
> Date: Sun, 16 Sep 2012 01:17:33 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: rms <at> gnu.org, 12450 <at> debbugs.gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:25:01 GMT) Full text and rfc822 format available.Message #56 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 01:23:28 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:26:01 GMT) Full text and rfc822 format available.Message #59 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 11:24:02 +0300
> Date: Sun, 16 Sep 2012 01:17:33 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: rms <at> gnu.org, 12450 <at> debbugs.gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:34:01 GMT) Full text and rfc822 format available.Message #62 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 11:32:19 +0300
> Date: Sun, 16 Sep 2012 01:23:28 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: rms <at> gnu.org, lekktu <at> gmail.com, 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:36:01 GMT) Full text and rfc822 format available.Message #65 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 01:34:52 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 08:55:02 GMT) Full text and rfc822 format available.Message #68 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 11:53:33 +0300
> Date: Sun, 16 Sep 2012 01:34:52 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: rms <at> gnu.org, 12450 <at> debbugs.gnu.org, lekktu <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 09:36:01 GMT) Full text and rfc822 format available.Message #71 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Daniel Colascione <dancol <at> dancol.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 02:33:45 -0700
[Message part 1 (text/plain, inline)]
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.
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 09:55:01 GMT) Full text and rfc822 format available.Message #74 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Daniel Colascione <dancol <at> dancol.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 02:52:35 -0700
[Message part 1 (text/plain, inline)]
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.
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 10:45:02 GMT) Full text and rfc822 format available.Message #77 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Daniel Colascione <dancol <at> dancol.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 13:43:10 +0300
> Date: Sun, 16 Sep 2012 02:33:45 -0700 > From: Daniel Colascione <dancol <at> dancol.org> > CC: Paul Eggert <eggert <at> cs.ucla.edu>, lekktu <at> gmail.com, > 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 10:46:02 GMT) Full text and rfc822 format available.Message #80 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Daniel Colascione <dancol <at> dancol.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 13:44:18 +0300
> Date: Sun, 16 Sep 2012 02:52:35 -0700 > From: Daniel Colascione <dancol <at> dancol.org> > CC: Eli Zaretskii <eliz <at> gnu.org>, lekktu <at> gmail.com, rms <at> gnu.org, > 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 10:58:02 GMT) Full text and rfc822 format available.Message #83 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Daniel Colascione <dancol <at> dancol.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 03:56:20 -0700
[Message part 1 (text/plain, inline)]
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.
[signature.asc (application/pgp-signature, attachment)]
bug-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 15:00:02 GMT) Full text and rfc822 format available.Message #86 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Monnier <monnier <at> iro.umontreal.ca> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. 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. - 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 15:12:01 GMT) Full text and rfc822 format available.Message #89 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Monnier <monnier <at> iro.umontreal.ca> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>, eggert <at> cs.ucla.edu Subject: Re: bug#12450: Remove configure's --without-sync-input option. 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. ] 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 15:43:02 GMT) Full text and rfc822 format available.Message #92 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: lekktu <at> gmail.com, 12450 <at> debbugs.gnu.org, dancol <at> dancol.org, eggert <at> cs.ucla.edu Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 18:40:53 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca> > Cc: Daniel Colascione <dancol <at> dancol.org>, lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 15:47:02 GMT) Full text and rfc822 format available.Message #95 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 18:45:25 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca> > Cc: eggert <at> cs.ucla.edu, lekktu <at> gmail.com, 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 16:32:01 GMT) Full text and rfc822 format available.Message #98 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 09:30:27 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 18:39:01 GMT) Full text and rfc822 format available.Message #101 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Stefan Monnier <monnier <at> iro.umontreal.ca> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 14:37:42 -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? 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 18:42:02 GMT) Full text and rfc822 format available.Message #104 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, monnier <at> iro.umontreal.ca, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 21:40:18 +0300
> Date: Sun, 16 Sep 2012 09:30:27 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, lekktu <at> gmail.com, > 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sun, 16 Sep 2012 19:57:02 GMT) Full text and rfc822 format available.Message #107 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Jan Djärv <jan.h.d <at> swipnet.se> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 21:55:27 +0200
16 sep 2012 kl. 20:40 skrev Eli Zaretskii <eliz <at> gnu.org>: >> Date: Sun, 16 Sep 2012 09:30:27 -0700 >> From: Paul Eggert <eggert <at> cs.ucla.edu> >> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, lekktu <at> gmail.com, >> 12450 <at> 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.
Paul Eggert <eggert <at> cs.ucla.edu>
:Paul Eggert <eggert <at> cs.ucla.edu>
:Message #112 received at 12450-done <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450-done <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 14:48:55 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Mon, 17 Sep 2012 07:43:02 GMT) Full text and rfc822 format available.Message #115 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Daniel Colascione <dancol <at> dancol.org> Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Mon, 17 Sep 2012 10:41:25 +0300
> Date: Sun, 16 Sep 2012 03:56:20 -0700 > From: Daniel Colascione <dancol <at> dancol.org> > CC: eggert <at> cs.ucla.edu, lekktu <at> gmail.com, rms <at> gnu.org, > 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Mon, 17 Sep 2012 07:45:02 GMT) Full text and rfc822 format available.Message #118 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: lekktu <at> gmail.com, rms <at> gnu.org, 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Mon, 17 Sep 2012 10:42:44 +0300
> Date: Sun, 16 Sep 2012 14:48:55 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: rms <at> gnu.org, lekktu <at> gmail.com, 12450-done <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Fri, 21 Sep 2012 20:53:01 GMT) Full text and rfc822 format available.Message #121 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Fri, 21 Sep 2012 13:50:45 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 22 Sep 2012 09:06:01 GMT) Full text and rfc822 format available.Message #124 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 22 Sep 2012 12:03:50 +0300
> Date: Fri, 21 Sep 2012 13:50:45 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 22 Sep 2012 09:37:01 GMT) Full text and rfc822 format available.Message #127 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 22 Sep 2012 02:34:58 -0700
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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 22 Sep 2012 09:53:02 GMT) Full text and rfc822 format available.Message #130 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 22 Sep 2012 12:50:34 +0300
> Date: Sat, 22 Sep 2012 02:34:58 -0700 > From: Paul Eggert <eggert <at> cs.ucla.edu> > CC: 12450 <at> 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-gnu-emacs <at> gnu.org
:bug#12450
; Package emacs
.
(Sat, 22 Sep 2012 10:03:01 GMT) Full text and rfc822 format available.Message #133 received at 12450 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 12450 <at> debbugs.gnu.org Subject: Re: bug#12450: Remove configure's --without-sync-input option. Date: Sat, 22 Sep 2012 03:01:10 -0700
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.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Sat, 20 Oct 2012 11:24:03 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.