From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Threading IO-bound functions Date: Mon, 19 Dec 2016 19:32:57 +0200 Message-ID: <83pokn4yeu.fsf@gnu.org> References: <8360mj99oe.fsf@gnu.org> <83fulk610j.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1482168822 4487 195.159.176.226 (19 Dec 2016 17:33:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 17:33:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Elias =?utf-8?Q?M=C3=A5rtenson?= , =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 19 18:33:36 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ1oc-00008M-Pp for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 18:33:34 +0100 Original-Received: from localhost ([::1]:46990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ1og-00017J-UT for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 12:33:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ1ob-000178-EE for emacs-devel@gnu.org; Mon, 19 Dec 2016 12:33:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJ1oY-0007hP-61 for emacs-devel@gnu.org; Mon, 19 Dec 2016 12:33:33 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ1oY-0007hF-2P; Mon, 19 Dec 2016 12:33:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1781 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cJ1oX-0002sB-6R; Mon, 19 Dec 2016 12:33:29 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Mon, 19 Dec 2016 15:06:32 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210645 Archived-At: > From: Elias Mårtenson > Date: Mon, 19 Dec 2016 15:06:32 +0800 > Cc: emacs-devel > > 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 > 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.