From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: lekktu@gmail.com, 12450@debbugs.gnu.org
Subject: bug#12450: Remove configure's --without-sync-input option.
Date: Sat, 15 Sep 2012 03:14:50 -0700 [thread overview]
Message-ID: <5054551A.1070207@cs.ucla.edu> (raw)
In-Reply-To: <83k3vvtyw0.fsf@gnu.org>
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.)
next prev parent reply other threads:[~2012-09-15 10:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-15 7:54 bug#12450: Remove configure's --without-sync-input option Paul Eggert
2012-09-15 9:32 ` Eli Zaretskii
2012-09-15 10:14 ` Paul Eggert [this message]
2012-09-15 11:03 ` Eli Zaretskii
2012-09-15 19:59 ` Paul Eggert
2012-09-15 20:15 ` Eli Zaretskii
2012-09-15 20:31 ` Paul Eggert
2012-09-16 6:33 ` Eli Zaretskii
2012-09-16 7:47 ` Paul Eggert
2012-09-16 8:05 ` Eli Zaretskii
2012-09-16 8:17 ` Paul Eggert
2012-09-16 8:21 ` Eli Zaretskii
2012-09-16 8:24 ` Eli Zaretskii
2012-09-16 8:34 ` Paul Eggert
2012-09-16 8:53 ` Eli Zaretskii
2012-09-15 21:12 ` Stefan Monnier
2012-09-16 5:55 ` Eli Zaretskii
2012-09-16 14:58 ` Stefan Monnier
2012-09-16 15:45 ` Eli Zaretskii
2012-09-16 16:30 ` Paul Eggert
2012-09-16 18:40 ` Eli Zaretskii
2012-09-16 19:55 ` Jan Djärv
2012-09-16 18:37 ` Stefan Monnier
2012-09-16 9:33 ` Daniel Colascione
2012-09-16 10:43 ` Eli Zaretskii
2012-09-16 15:10 ` Stefan Monnier
2012-09-16 15:40 ` Eli Zaretskii
2012-09-15 22:18 ` Richard Stallman
2012-09-16 3:15 ` Paul Eggert
2012-09-16 6:10 ` Eli Zaretskii
2012-09-16 8:23 ` Paul Eggert
2012-09-16 8:32 ` Eli Zaretskii
2012-09-16 21:48 ` Paul Eggert
2012-09-17 7:42 ` Eli Zaretskii
2012-09-21 20:50 ` Paul Eggert
2012-09-22 9:03 ` Eli Zaretskii
2012-09-22 9:34 ` Paul Eggert
2012-09-22 9:50 ` Eli Zaretskii
2012-09-22 10:01 ` Paul Eggert
2012-09-16 9:52 ` Daniel Colascione
2012-09-16 10:44 ` Eli Zaretskii
2012-09-16 10:56 ` Daniel Colascione
2012-09-17 7:41 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5054551A.1070207@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=12450@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.