From: Eli Zaretskii <eliz@gnu.org>
To: "Elias Mårtenson" <lokedhs@gmail.com>,
"Clément Pit--Claudel" <clement.pit@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Threading IO-bound functions
Date: Mon, 19 Dec 2016 19:32:57 +0200 [thread overview]
Message-ID: <83pokn4yeu.fsf@gnu.org> (raw)
In-Reply-To: <CADtN0WKmYP4NX8D0fQw1OYY5-XU1b1ioS3ek0APZs8LQRpURMg@mail.gmail.com> (message from Elias Mårtenson on Mon, 19 Dec 2016 15:06:32 +0800)
> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Mon, 19 Dec 2016 15:06:32 +0800
> Cc: emacs-devel <emacs-devel@gnu.org>
>
> I asked for thoughts and ideas about this in bug#25214. So far no
> replies, which I find unfortunate and, frankly, surprising.
>
> I thought that I had been reading all the concurrency-related threads, but I don't recall seeing this. If it was only
> mentioned in a bug report it doesn't surprise me that not so many people see it.
All the people whom I expected to respond are either subscribed to the
bug list or were explicitly CC'ed ;-)
> Now, my thoughts on this is that keyboard entry is an inherently single-threaded operation from the user's
> point of view and that the Emacs platform should enforce this. Thus, keyboard input should only be allowed
> from the main thread.
That is not the only possibility: we could also serialize minibuffer
input. (Note that keyboard input per se is not an issue: the
implementation of threads already lets just one thread at a time wait
on keyboard input.)
> Naturally, a threaded function may want to invoke ‘or-or-n-p’ or ‘read-string’ or other similar things. This should
> be implemented using a queue where the thread places an input request on the queue and waits for the main
> thread to reply with the result. The main thread would see the request on the queue and invoke the appropriate
> keyboard-interaction-function at the appropriate time.
The general idea is almost a no-brainer, but the devil is in the
details. I'm afraid asking another thread to do minibuffer input
might only work on a very low level, because of the thread-specific
bindings and other thread-specific stuff. So any Lisp code or code on
similar levels (e.g., C code that is "just below" Lisp) cannot be run
"on behalf of another thread", as it will not generally DTRT. And
that contradicts your idea, I think, because it presumes putting some
high-level Lisp objects on those queues.
> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Sun, 18 Dec 2016 23:31:28 -0500
>
> Alternatively, could we simply disallow this type of interaction until we have a good story about it? That would bring us closer to the way web workers work in Javascript (they need to post a message to interact with the UI/DOM).
How exactly do we "disallow" that? Let's keep in mind that Emacs
generally does UI very casually, and many times out of control of the
application-level code. For example, modifying a buffer might pop up
the "supersession threat" prompt without any prior notice. What would
"disallow" mean in that case? always answer a standard answer
automatically? signal an error? How can an application protect itself
against something like that, when it's hard to know in advance it will
happen? We don't want to require that code that can be run from
non-primary threads be written using some special very restrictive
techniques, at least not without trying to find better solutions.
next prev parent reply other threads:[~2016-12-19 17:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 4:01 Threading IO-bound functions Elias Mårtenson
2016-12-16 15:26 ` Eli Zaretskii
2016-12-19 3:03 ` Elias Mårtenson
2016-12-19 3:39 ` Eli Zaretskii
2016-12-19 7:06 ` Elias Mårtenson
2016-12-19 17:32 ` Eli Zaretskii [this message]
2016-12-19 17:43 ` The event handling thread (was: Threading IO-bound functions) John Wiegley
2016-12-20 16:08 ` Eli Zaretskii
2016-12-21 1:04 ` The event handling thread John Wiegley
2016-12-21 11:05 ` Elias Mårtenson
2016-12-21 17:42 ` Eli Zaretskii
2016-12-22 3:12 ` Elias Mårtenson
2016-12-22 17:37 ` Eli Zaretskii
2016-12-16 22:05 ` Threading IO-bound functions Ken Raeburn
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=83pokn4yeu.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=clement.pit@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=lokedhs@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.