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: Mon, 27 Aug 2018 18:06:25 +0300 Message-ID: <8336uz6e8e.fsf@gnu.org> 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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535382754 10577 195.159.176.226 (27 Aug 2018 15:12:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 15:12:34 +0000 (UTC) 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: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 27 17:12:29 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 1fuJBt-0002b5-8u for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 17:12:29 +0200 Original-Received: from localhost ([::1]:33842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuJDy-000212-Ny for ged-emacs-devel@m.gmane.org; Mon, 27 Aug 2018 11:14:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuJDh-0001p2-BL for emacs-devel@gnu.org; Mon, 27 Aug 2018 11:14:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuJ6E-0004oL-W3 for emacs-devel@gnu.org; Mon, 27 Aug 2018 11:06:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuJ6E-0004oH-Rk; Mon, 27 Aug 2018 11:06:38 -0400 Original-Received: from [176.228.60.248] (port=3915 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fuJ68-0007Fc-Nt; Mon, 27 Aug 2018 11:06:33 -0400 In-reply-to: <871sakl97g.fsf@himinbjorg.adminart.net> (message from hw on Mon, 27 Aug 2018 06:33:39 +0200) 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:228974 Archived-At: > 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. > 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. > 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. > 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 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.