GNU bug report logs -
#12450
Remove configure's --without-sync-input option.
Previous Next
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.
Full log
View this message in rfc822 format
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.)
This bug report was last modified 12 years and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.