Re: Threading IO-bound functions

[Eli Zaretskii]

> From: Elias Mårtenson <address@hidden>
> Date: Mon, 19 Dec 2016 15:06:32 +0800
> Cc: emacs-devel <address@hidden>
> 
>  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 <address@hidden>
> 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.