From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Mon, 27 Aug 2018 21:46:30 +0200 Organization: my virtual residence Message-ID: <877ekbego9.fsf@himinbjorg.adminart.net> References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> <83a7phdl7r.fsf@gnu.org> <61492e7f622303d02405bedbe65fabae@webmail.orcon.net.nz> <83pnybdaer.fsf@gnu.org> <837ekicw7i.fsf@gnu.org> <877ekiierh.fsf@himinbjorg.adminart.net> <834lflb2fj.fsf@gnu.org> <83h8jk9l41.fsf@gnu.org> <8336v2994c.fsf@gnu.org> <83bm9q6x7v.fsf@gnu.org> <874lfi863s.fsf@himinbjorg.adminart.net> <83va7x5guc.fsf@gnu.org> <871sakl97g.fsf@himinbjorg.adminart.net> <8336uz6e8e.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535399247 29554 195.159.176.226 (27 Aug 2018 19:47:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 19:47:27 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 27 21:47:22 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 1fuNTt-0007Xf-OZ for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 21:47:22 +0200 Original-Received: from localhost ([::1]:34872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuNVz-0002GR-VS for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 15:49:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuNVq-0002Dm-DA for emacs-devel@gnu.org; Mon, 27 Aug 2018 15:49:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuNTS-0007ks-Kp for emacs-devel@gnu.org; Mon, 27 Aug 2018 15:46:55 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::11]:33999) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fuNTO-0007hn-Aw; Mon, 27 Aug 2018 15:46:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535399207; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=YHnlIvC8U1hCvlel6byeJooolHRXyLVECEjUOwLQvjg=; b=mc1F3vnQhiCTGAuqBCE56yJ2BO+rOgy773lKbElBuc6N8qnM9Dt84MrwBhzUnejzQy r0Jk1RYXaCdJuCjUWpx71egsqkT4me3LfRFyIRldv14tNmgAKsskDulcdv2K3xKbawBM Ldnh2mUirkOfqGkfIJHe1G2Xv5p+/HhQvJDIoNGuaxwPTfkJgud6BMDkE5Y258dzulvB nmLxgyfM6XD+uyYfBxxeepIC30gk7JhaYfFASIfVPYGiKdISQlPmmlqQjdRE3ytJRhWo /qGsHQDoB2iwkFHXXCpDbUqkKh2d79Q2pRnijzKlOteWnM+unj23XUi0EMocno0pNt9c VRpA== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1fuNTD-0001nV-1a; Mon, 27 Aug 2018 21:46:39 +0200 In-Reply-To: <8336uz6e8e.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 27 Aug 2018 18:06:25 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::11 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:228987 Archived-At: Eli Zaretskii writes: >> From: hw >> Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org >> Date: Mon, 27 Aug 2018 06:33:39 +0200 >> >> > We all but agreed that threads should not "fight" one another. >> >> When you don't want threads to have to fight over the mini-buffer, each >> thread needs its own. > > Not necessarily: we could serialize the interactions. Users still require sequentiality to be able to deal with them. >> If that would be done, each mini-buffer would need its own history so >> users can look at it to remember what they were doing --- I think that >> was mentioned. >> >> Do you want to do that? > > It doesn't seem to solve the problem: Emacs still has to decide which > minibuffer to use when. And if you want to put that onus on the user, > then that same user could instead switch to thread N in the single > minibuffer we have now. true And if you want neither Emacs to decide which prompts to interrupt the user with, nor let the user decide which prompts to deal with, you're kinda out of options. >> How about: Emacs does not make this decision and does not let threads >> interact with users in this manner. It puts all requests for input onto >> the queue unless it can clearly determine that the request is directly >> related to what the user is doing or working with. > > Then the problem becomes how to manage that queue, and which part of > Emacs will do that. We are back to the same issue, just in a slightly > different form. Aren't the threads already managed in some way? The queue would provide the historical context, and the user dealing with queue-entry X would implicitly and transparently switch to thread N. >> What you seem to think you must do --- grant an arbitrary thread access >> to the mini-buffer --- is what you *must not* do. > > But in that case everything becomes sequential again, and we gained > nothing by introducing concurrency into Emacs. The queue circumvents this: it would allow to present sequentiality (by historical context and perhaps by grouping all requests by the operation they are involved with) to the user while the execution of threads can remain serialized. The disadvantage is that when there goes something wrong with a sequence (bad example: visiting a file before being prompted for a file name), the user may have a hard to time to notice that there is something wrong (unless the grouping by operation makes the queue entry appear in the wrong historical context maybe). > The only threads that will be able to run non-sequentially are those > that never need to tell the users or ask them anything, and that makes > this feature rather limited, I think. All threads can run in any arbitrary order as long as they queue their requests. The alternative is interrupting the users with prompts out of sequence so they do not know what Emacs wants, prompts serialized or not. Emacs could even assume the possible answers to a prompt and perform the actions resulting from the answers in some cases so that when the user makes a decision, the result is already available and the one not needed can be discarded :)