From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Tue, 14 Aug 2018 12:42:04 -0400 Message-ID: <87bma4528z.fsf@md5i.com> References: <838t59j821.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534268675 9252 195.159.176.226 (14 Aug 2018 17:44:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2018 17:44:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 14 19:44:30 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 1fpdMr-0002I9-D6 for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 19:44:29 +0200 Original-Received: from localhost ([::1]:45335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpdOx-0006V8-VE for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 13:46:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpdEH-00065w-O2 for emacs-devel@gnu.org; Tue, 14 Aug 2018 13:35:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpdDv-0003ej-Bw for emacs-devel@gnu.org; Tue, 14 Aug 2018 13:35:37 -0400 Original-Received: from md5i.com ([75.151.244.229]:55814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fpdDv-0003eK-4j for emacs-devel@gnu.org; Tue, 14 Aug 2018 13:35:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=md5i.com; s=dkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=le4MR7v2FCAtuO3hINH3a0w2irVTDL6DqpjlMUw44yc=; b=oOhobSW+5AMMfxRyPE0I0TEM/B PvUDX1Jekz/eQRMLrY0B9b6P/vXgP/WUSA0Ym/NSsZu0I/sRMJgm8DbUVavNM527xJdMTuXfFgVme L7+qnF0ID1/jHjkXkk8FganYk; Original-Received: from md5i by md5i.com with local (Exim 4.91) (envelope-from ) id 1fpcOS-00047J-1H for emacs-devel@gnu.org; Tue, 14 Aug 2018 12:42:04 -0400 In-Reply-To: <838t59j821.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Aug 2018 18:12:54 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 75.151.244.229 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:228532 Archived-At: Eli Zaretskii writes: > For background, see bugs #25214 and #32426. Some additional > discussion was here: > > http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00607.html > > I'm trying to revive those past discussion, because we now have a > serious and useful application that bumped into these problems, where > formerly we only had theoretical discussions and toy programs. > > After thinking some more about this, I think we should first pay > attention to conceptual issues related to this, before we start > talking about implementation. The conceptual problem I see here is > the UX when more than one thread needs to interact with the user. > > For the following description, recall that normally only the main > thread will wait on the keyboard descriptor (why that happens was > explained in bug#25214). > > 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? > > Thoughts? Here are nmy answers to your three use cases: #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. #2 You should neveer break a key sequence. We do not preempt the main thread. The other thread will have 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. Without trying to figure out how it would be implemented, I think I'd want the following: 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. 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. Sorry, this was very much stream-of-thought. -- Michael Welsh Duggan (md5i@md5i.com)