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: Thu, 16 Aug 2018 22:59:57 -0400 Message-ID: <874lft3dg2.fsf@md5i.com> References: <838t59j821.fsf@gnu.org> <87bma4528z.fsf@md5i.com> <834lfuie1i.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534474686 23214 195.159.176.226 (17 Aug 2018 02:58:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 02:58:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Michael Welsh Duggan , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 17 04:58:02 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 1fqUxd-0005tj-Vd for ged-emacs-devel@m.gmane.org; Fri, 17 Aug 2018 04:58:02 +0200 Original-Received: from localhost ([::1]:59704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqUzi-0004cd-Mn for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 23:00:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqUzc-0004cW-JK for emacs-devel@gnu.org; Thu, 16 Aug 2018 23:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqUzb-0003m4-K8 for emacs-devel@gnu.org; Thu, 16 Aug 2018 23:00:04 -0400 Original-Received: from md5i.com ([75.151.244.229]:41520) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fqUzY-0003i7-2P; Thu, 16 Aug 2018 23:00:00 -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:Cc:To:From:Sender:Reply-To: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=MEWnOLRsmkmpye1Vzq/XVZ0gH8TUHaSmAis+mWoPVW8=; b=v02dwzVFzZUs270uZYrlLYofpc it2+0MonZno7s0ASm04Rztygf8vfYLAgGN29HAJJaFb7WILeSUH+UVlWjb97YmnQzsMIRhYsRVA29 Xrp+P/vtFNolXenvbG4TQZ93b; Original-Received: from md5i by md5i.com with local (Exim 4.91) (envelope-from ) id 1fqUzV-0003QK-3k; Thu, 16 Aug 2018 22:59:57 -0400 In-Reply-To: <834lfuie1i.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Aug 2018 17:25:45 +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:228616 Archived-At: Eli Zaretskii writes: >> 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. To clarify, I believe the command-loop (main-thread), aside from a large amount of maintainance, is fundamentally a loop around read-key-sequence, lookup-key, and command-execute. *This* read-key-sequence needs to be interruptable by other threads as long as no keys have yet been entered into the sequence. This is the point I considered to be "idling." If any other thread, or even the main thread, calls read-key-sequence outside of the main command-loop, that one should get the input mutex immediately. You probably understand what I mean at this point, but to clarify, in case: Another thread should not be blocked for input because the main thread is waiting for an event, unless the main thread is waiting for that event because it explicitly called read-key-sequence or some other higher-level input function (such as read-from-minibuffer) from anything other than the command loop. But the instant the command loop's read-key-sequence reads a single key, it must have the input mutex until it has finished reading a key sequence (or is quit). Now, another command -- say, read-from-minibuffer -- could end up calling the command loop, which will look for events. That command should have set the input mutex beforehand, and, to be clear, this should be a recursive mutex, so it won't be interrupted in this context. A call to recursive-edit, however, would not (I think) grab the input mutex, and as such would still yield to an input request from another thread. I have no idea what would be caused by a non-main thread calling recursive-edit. That way lies madness. But someone should consider what it might mean. >> #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? No. Just wait for the current input sequence to finish, then allow the prompt. I suppose there could be indicators in the mode line, or something like that, but I don't think we need that initialy, and I have no idea whether that would actually be desirable anyway. >> 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. No problem. As my employer makes it unfeasibly difficult to contribute code to the FSF (would have to have a separate disclaimer for every feature), participating in discussions like this is the least I can do. -- Michael Welsh Duggan (md5i@md5i.com)