From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Mon, 20 Aug 2018 13:18:15 +1200 Message-ID: References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534727796 21701 195.159.176.226 (20 Aug 2018 01:16:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 01:16:36 +0000 (UTC) User-Agent: Orcon Webmail Cc: Eli Zaretskii , Emacs-devel , emacs-devel@gnu.org To: Gemini Lasswell Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 03:16:32 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 1frYo3-0005WT-FB for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 03:16:31 +0200 Original-Received: from localhost ([::1]:44619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frYq9-0003tT-DV for ged-emacs-devel@m.gmane.org; Sun, 19 Aug 2018 21:18:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frYpw-0003sa-1W for emacs-devel@gnu.org; Sun, 19 Aug 2018 21:18:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frYpv-00047A-6k for emacs-devel@gnu.org; Sun, 19 Aug 2018 21:18:27 -0400 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:49025) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frYpp-00042d-S0; Sun, 19 Aug 2018 21:18:22 -0400 Original-Received: from [10.253.37.70] (port=18184 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1frYpj-0005hv-Fo; Mon, 20 Aug 2018 13:18:15 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 20 Aug 2018 13:18:15 +1200 In-Reply-To: <87lg92q7ih.fsf@runbox.com> X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 60.234.4.59 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:228703 Archived-At: On 2018-08-20 11:08, Gemini Lasswell wrote: > Perhaps the way to accomplish this is to always read keyboard input in > the main thread. So when read-from-minibuffer, for example, is called > from a non-main thread, it would put the prompt on a queue for the main > thread to process, and then block until the response is ready. >> 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? > > The first thread should get to show its prompt and wait for a response, > and then show followup prompts if it can present them immediately after > the first is answered. Other threads will block until the threads > ahead > of them are done prompting. I'm pondering the details of that "and then show followup prompts if it can present them immediately" part... Say a thread has pushed its first prompt onto a queue, and then blocked. At this point there is no knowledge of whether or not that thread may have follow-up prompts to issue once it is unblocked. In the meantime, additional threads may also push prompts onto the queue. Once it's safe for the user to be prompted, the first thread's prompt is processed in the main thread, and the result is established and passed back to the calling thread, which then resumes processing. So long as that thread doesn't voluntarily yield, it would be able to generate a follow-up prompt before any of the other pending prompts from other threads had a chance to be processed. However, it's also going to need to jump the queue. If the main thread is managing the queue of pending prompts, is it sufficient for the main thread to track the single most-recent thread with which the user interacted, and to always prioritise queue items from that thread over any other queue items? -Phil