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: Tue, 21 Aug 2018 10:38:59 +1200 Message-ID: <61492e7f622303d02405bedbe65fabae@webmail.orcon.net.nz> References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> <83a7phdl7r.fsf@gnu.org> 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 1534804630 17313 195.159.176.226 (20 Aug 2018 22:37:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 22:37:10 +0000 (UTC) User-Agent: Orcon Webmail Cc: Gemini Lasswell , Emacs-devel , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 21 00:37:06 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 1frsnJ-0004Q3-Qm for ged-emacs-devel@m.gmane.org; Tue, 21 Aug 2018 00:37:05 +0200 Original-Received: from localhost ([::1]:49568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frspQ-0001Xw-BN for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 18:39:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frspK-0001Xf-0i for emacs-devel@gnu.org; Mon, 20 Aug 2018 18:39:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frspJ-0005NW-5b for emacs-devel@gnu.org; Mon, 20 Aug 2018 18:39:09 -0400 Original-Received: from smtp-3.orcon.net.nz ([60.234.4.44]:57703) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frspD-0005Jx-Lj; Mon, 20 Aug 2018 18:39:03 -0400 Original-Received: from [10.253.37.70] (port=52022 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1frsp9-0007EG-Bp; Tue, 21 Aug 2018 10:38:59 +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); Tue, 21 Aug 2018 10:38:59 +1200 In-Reply-To: <83a7phdl7r.fsf@gnu.org> 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.44 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:228767 Archived-At: On 2018-08-21 05:03, Eli Zaretskii wrote: > Remember: the prompting thread called some function, like > read-file-name, and that function has its own ideas for how to > interact with the user -- how will the prompting thread tell the > main thread all those details? Some of the details reference > variables that are local to the prompting thread's current-buffer, > about which the main thread knows nothing. The main thread will > need to thoroughly "emulate" the prompting thread to DTRT here. I was wondering about this too, and concluded that the main thread probably can't read the input (for the reasons you've outlined), but that the more general approach of the main thread *coordinating* the reading of input based on information from the other threads might still be viable and useful. Instead of the prompting thread pushing its prompt into a queue for the main thread to somehow execute, the prompting thread could instead simply push onto a queue a *notification* that it needs to perform some user interaction. At that point, as in the prior suggestion, it blocks until the main thread decides that the user-interaction is safe. But instead of the main thread reading the input itself and then passing control (and the result) back, it simply passes control back to the prompting thread -- which will read the input for itself and continue processing. I think that's the same outcome as the prior suggestion, but without the magic of one thread knowing all about another thread. The queue is then essentially the list of threads which are awaiting the opportunity to perform user-interaction. When a non-main thread attempts to read input from the user, it is automatically blocked and pushed onto the queue. Any thread which is blocked on this account is only allowed to resume when Emacs decides that it is safe for user interaction for a non-main thread to occur. And my thought about queue-jumping procedures would still work the same as before, so that a single thread could read a series of user inputs without other threads interjecting with their own reads. -Phil p.s. I'm afraid I've not been following the whole discussion, so apologies if I'm just covering old ground here, or ignoring other critical elements.