From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 15 Aug 2018 10:02:13 +0200 Message-ID: <87600cukfu.fsf@gmx.de> References: <838t59j821.fsf@gnu.org> <87bma4528z.fsf@md5i.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534320101 27349 195.159.176.226 (15 Aug 2018 08:01:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Aug 2018 08:01:41 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 15 10:01:37 2018 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 1fpqkK-0006yj-Lk for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2018 10:01:36 +0200 Original-Received: from localhost ([::1]:47877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpqmR-0000hK-3P for ged-emacs-devel@m.gmane.org; Wed, 15 Aug 2018 04:03:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpqmH-0000fB-EA for emacs-devel@gnu.org; Wed, 15 Aug 2018 04:03:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpqlI-00028q-20 for emacs-devel@gnu.org; Wed, 15 Aug 2018 04:02:44 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:49185) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fpql7-00024t-QJ for emacs-devel@gnu.org; Wed, 15 Aug 2018 04:02:29 -0400 Original-Received: from detlef.gmx.de ([79.140.117.178]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lat5o-1gIKxb0Koy-00kSLt; Wed, 15 Aug 2018 10:02:15 +0200 In-Reply-To: <87bma4528z.fsf@md5i.com> (Michael Welsh Duggan's message of "Tue, 14 Aug 2018 12:42:04 -0400") X-Provags-ID: V03:K1:0sUSfms//pxc4cwMA2+d4gvQZe4mwmekOltEitSXAxd9F7V8bqF dbYCcDzwM+G2P3MtHZgp4EeCo5Vvx8PFyfIvdxl7xvvNmcBUwfrC9XZsqeREsi++Z+1uRES VAuwf1xuixoJCEIKAWwuZ7Q6OgluDIPJaOQrzboYLEEggzpGz4O9QyXCeZCYiHHobg5mw+s lfdgDm5Ia9L4nwPAriJYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gmSzGx8jsWo=:/uSLeN+VFEqxYwZ9VITH5x WHXSGOl1kvu9H0VP1et137nr0YF0xKhS1vWP2KPcYsbllCBqnMMrrCuKOVq2lku79e6T5Pv8y q/OeNx5X/58cZ5zZN1DLOj+VQTP/nGtl0/KjaZgWDf1WcRiitQzGT8byfTBmjM9UIV8wVp/XY qSvimCXSZ5hnhVR+J8SsJUFTlXYYaBWzK7z9t9VB6qwbWHzCNzn1zp1LDThJaLmIpNihxTKA8 YaGHrPgLw+v4uGPQ7lFx4wPTTnZpXiZKg3CMqXvFMJaa78z6yng+9aOYiGuCyggjPrCLvIkui 53YFX4DVb+u+FyyzRDwpacqmITrvu1UA523J/t4gzwgjoqZQfzjgzUT5/kmflwSWOQy1TkBIk DOUnQDKOYHjCQBFebiZsv+wiAKLbWt2xxV+qtT6PQBTqP/JV59FuQTTEY2Ndf04gIwUqm7E3b NDoUNObS9b759YK/D65PGH0s69TBlHqZduxov1FDSr15XGPr2J3ULT+iUa+twXxSGAjrbFkmo rWl3PQq9GG0hO3rW2I3EnMziTdHndicw0XBaQwnnz2cXZ9lbHCgO5vLru83Ltwo99C8E8wJTW h4lRBeqw23N3UerzpOAvGVkkAkiXKgEYOzffW9F0qaxtVCOddBTtfW5wyz8DM/wscrYd4mPcO JBV9i9ytp3bjFbfb3ccWT4lR6w1dDziwfHwjPSdn0aw/MnU6tsC+RqS1wHdXdmoXOSZpJJqXW xGFYvZfCSbBV0TWWbZnH9PwSUvUVSqhBjXxJ8I/5JteV7URTLd2gGZTMV3KUtqWIAtIE+EoN X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Received-From: 212.227.17.21 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:228548 Archived-At: Michael Welsh Duggan writes: Hi, >> Use case #1: >> >> . The main thread is waiting for user input. The user didn't yet >> type anything >> . A non-main thread runs Lisp that prompts the user for some input >> >> In this case, we probably want the following input to go to the >> prompting thread, right? But it might also be the case that the >> user actually wants the input to go to the main thread, e.g. to >> perform some unrelated command. Should we allow that? If yes, how >> should Emacs know which thread should receive what the user types? >> >> Use case #2: >> >> Same as the previous, but now the user is in the middle of typing a >> key sequence, when the non-main thread prompts. For example, >> suppose the user has typed "C-x". >> >> What do we want to happen now? Do we "preempt" the main thread and >> let the following input to go to the prompting thread? Or do we let >> the prompting thread wait until the main thread reads a full key >> sequence and runs the command bound to it? If the former, what to >> do with the partial key sequence ("C-x") that the user typed? If >> the latter, how do we indicate to the user that there is a prompt >> from another thread? >> >> Use case #3: >> >> Similar, but now 2 or more non-main threads prompt the user, one >> after the other, in quick succession. What should happen now, and >> how will the user know there are multiple prompts? > > #1 If "waiting for input" means in read-from-minibuffer or something > similar, I believe that input should go to the the thread. The other > thread will have to wait. If "waiting for input" means idle, it > should go the the other thread. I agree. If there is already a prompt in the minibuffer, the input shall be related to that prompt. If the user wants to do something else (enter a command for the main thread), she shall cancel the existing prompt with C-g. Maybe we shall mark the requesting thread for user input somehow, for example by a modeline indicator with related help-echo. > #2 You should neveer break a key sequence. We do not preempt the main > thread. The other thread will have to wait. I agree. If a user has started typing input, no other thread shall interrupt this by showing its own prompt, and reading own input. The other thread has to wait. > #3 Each thread should get to ask its question in turn, with its own > prompt. Other threads will block until that question is answered. > The user will know there are multiple prompts because after they > answer one, they get asked another. Agreed. The prompts must be designed such a way, that a user knows what she is responding to. She cannot expect a defined order of the prompts. For example, when answering a question about a file, the prompt shall always contain the file name the question is related to. > User input has to have a beginning and an end. The simple cases are > easy: a single full key sequence or a read-from-minibuffer call. But in > many cases an application has a series of prompts to be asked and > answered in succession. So these inputs need to be able to be grouped > somehow along with their prompts. Then, once a group is executing, any > other input-related groups raised by other threads have to wait for the > current input group to finish. Then they cay be served in FIFO or > random order. > > The easiest was I can think of grouping sets of inputs is as some form > of critical section, maybe implemented by mutexes. This would be > simplified for the programmer with a convenience wrapper, something like > (with-input-group BODY) or some such. Would be useful for new and adapted code. > Unfortunately, this proposal suffers in that it would have to be > retroactively added to existing code. So for existing code, some form > of heuristic will have to be used instead. The only one that comes to > mind is this: Once an input sequence begins, input is locked to that > thread until that thread ends, explicitly ends input operations (with > some new directive), or (in the case of the main thread) returns to the > command loop. Now, I can see problems with that. What happens when a > thread prompts for input and then sits and blocks waiting for something > else? Unless we can categorize certain blocking operations as ones that > will release the input mutex. I don't agree with this heuristic. Even if we don't run into deadlocks, one thread with a simple y-or-n-p question would block all other threads until it finishes, which could take time. We must accept that for not adapted code user input is requested from different threads, in random order. The only guarantee is, that user input for the same thread is in predefined order. Over the time, code will be adapted for threads to use the grouping feature as proposed above. > Sorry, this was very much stream-of-thought. Same here. Best regards, Michael.