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: User interaction from multiple threads Date: Thu, 16 Aug 2018 17:25:45 +0300 Message-ID: <834lfuie1i.fsf@gnu.org> References: <838t59j821.fsf@gnu.org> <87bma4528z.fsf@md5i.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534429456 13833 195.159.176.226 (16 Aug 2018 14:24:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 14:24:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 16 16:24:12 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 1fqJC7-0003Ul-90 for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 16:24:11 +0200 Original-Received: from localhost ([::1]:56029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqJEC-0003DD-3G for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 10:26:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqJDz-0003BV-V3 for emacs-devel@gnu.org; Thu, 16 Aug 2018 10:26:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqJDv-0005jz-Ld for emacs-devel@gnu.org; Thu, 16 Aug 2018 10:26:07 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqJDv-0005jv-HC; Thu, 16 Aug 2018 10:26:03 -0400 Original-Received: from [176.228.60.248] (port=2552 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fqJDq-0002Q0-4t; Thu, 16 Aug 2018 10:25:59 -0400 In-reply-to: <87bma4528z.fsf@md5i.com> (message from Michael Welsh Duggan on Tue, 14 Aug 2018 12:42:04 -0400) 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:228593 Archived-At: > From: Michael Welsh Duggan > Date: Tue, 14 Aug 2018 12:42:04 -0400 > > #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. "Waiting for input" means waiting for user to type something. That is normal Emacs situation when the user does nothing, so unconditionally sending input to the main thread and letting the other thread wait would mean that other thread might wait indefinitely. > #2 You should neveer break a key sequence. We do not preempt the main > thread. The other thread will have to wait. Do we need to tell the user the other thread wants to prompt? > 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. Not necessarily, it could be added to the corresponding primitives. Thanks.