From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Uday Reddy Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Thu, 30 Aug 2018 01:21:51 +0100 Message-ID: <23431.14495.866000.957305@gargle.gargle.HOWL> References: <838t59j821.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1535588404 4807 195.159.176.226 (30 Aug 2018 00:20:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2018 00:20:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 02:19:59 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 1fvAgo-00017n-S9 for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2018 02:19:58 +0200 Original-Received: from localhost ([::1]:45459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvAiv-0006yq-7R for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 20:22:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvAik-0006xt-VG for emacs-devel@gnu.org; Wed, 29 Aug 2018 20:21:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvAig-0001KM-0H for emacs-devel@gnu.org; Wed, 29 Aug 2018 20:21:58 -0400 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]:35273) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fvAif-0001I9-Ov for emacs-devel@gnu.org; Wed, 29 Aug 2018 20:21:53 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fvAie-0005rQ-NZ for emacs-devel@gnu.org; Thu, 30 Aug 2018 01:21:52 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk (envelope-from ) with esmtp (Exim 4.90_1) id 1fvAie-0000Fd-DX for emacs-devel@gnu.org using interface smart1.bham.ac.uk; Thu, 30 Aug 2018 01:21:52 +0100 Original-Received: from cca-132309.cs.bham.ac.uk ([147.188.193.190]) by mx1.cs.bham.ac.uk with esmtp (Exim 4.90_1) (envelope-from ) id 1fvAaq-0005uW-MO for emacs-devel@gnu.org; Thu, 30 Aug 2018 01:13:48 +0100 In-Reply-To: <838t59j821.fsf@gnu.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-mingw32) X-BHAM-SendViaRouter: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 147.188.128.137 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:229079 Archived-At: Sorry for getting into this discussion a bit late: > 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 I guess it is obvious that the non-main thread shouldn't interfere until the main thread's interaction is completed. > 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". Again, the non-main thread shouldn't interfere. > 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? I don't see "quick succession" as being an issue. The user is going to take his/her own time to answer. So, it can't happen too quickly. But the problem in my mind is that the main thread could be prompting for multiple things, e.g., think of M-x ediff-files. The non-main thread shouldn't interference until all of those are completed. Probably in many cases, the mutliple prompts all come from the same (interactive...) form, in which case all of them need to complete before another thread can start prompting. Now suppose multiple related prompts come from separate calls in the main thread. Then there must be a way to tie all those calls together, in the manner of a database transaction, and another thread be allowed to prompt only after the transaction completes. I think the database transaction model is a good one to follow here. Cheers, Uday