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: Sat, 25 Aug 2018 10:51:47 +0300 Message-ID: <8336v2994c.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535183411 20044 195.159.176.226 (25 Aug 2018 07:50:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 07:50:11 +0000 (UTC) Cc: psainty@orcon.net.nz, hw@adminart.net, emacs-devel@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, gazally@runbox.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 25 09:50: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 1ftTKf-00056g-Vu for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 09:50:06 +0200 Original-Received: from localhost ([::1]:44920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftTMm-0000Cb-2K for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 03:52:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftTMg-0000CO-0y for emacs-devel@gnu.org; Sat, 25 Aug 2018 03:52:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftTMc-0007Hq-05 for emacs-devel@gnu.org; Sat, 25 Aug 2018 03:52:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftTMb-0007Hk-SH; Sat, 25 Aug 2018 03:52:05 -0400 Original-Received: from [176.228.60.248] (port=4155 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ftTMV-0003DC-Oq; Sat, 25 Aug 2018 03:52:00 -0400 In-reply-to: (message from Richard Stallman on Fri, 24 Aug 2018 20:20:48 -0400) 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:228889 Archived-At: > From: Richard Stallman > Cc: psainty@orcon.net.nz, hw@adminart.net, gazally@runbox.com, > emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, > emacs-devel@gnu.org > Date: Fri, 24 Aug 2018 20:20:48 -0400 > > > The idea expressed by several people is that once you start > > interacting with some thread's prompt, the other threads are locked > > out of interaction, until the interacting thread is done with the > > series of prompts that allow it to go on with its business. > > This might be ok if the thread's further prompts arrive in short > succession. But what if it runs for 5 minutes and then asks > for input? Should other threads be blocked for those 5 minutes? If that thread runs (i.e. does some Lisp and never calls wait_reading_process_output), all the other threads will be blocked anyway, because the global lock is taken by the running thread. > I think the point of multiple threads is to avoid that. To some degree. > Would a thread explicitly seize the terminal and hold it and > later release it? Or would asking for input hold the terminal My conclusion from the discussion is that when a thread asks for input, it might be too late, because the prompt was already issued. But maybe we will be able to do something in the redisplay code to prevent the prompt from showing, in which case the terminal could indeed be seized when asking for input. If not, it will have to be seized just before issuing the prompt. > until the thread exits? Not until it exits, until it no longer needs to interact with the user, for the current transaction (whatever that means). > > If that's the first prompt in a series of prompts, we should fix the > > prompt to tell what password does it ask for. > > I don't think that is practical to do in all cases. In some, yes. > But what if two threads run the same function? The prompt could be > identical. I'd need a practical example to discuss this in more detail. Theoretically, you are right, but in practice it could be that the responses are identical (in which case it doesn't matter what thread asks the question). Or the prompts will have to be upgraded to speak for themselves, for example: Host for accessing file FOO: Password for accessing file FOO: etc. > > And even if we do require each thread to have a name, what guarantees > > do we have that the name will be more informative than the prompts > > about which you were worried? > > If we tell people, "Give your thread a meaningful name if it is going > to ask for input", and we explain why, they will mostly do it. > When they don't, we can fix it. I'm saying that fixing the prompt itself is a better alternative, because we will always give the prompt more screen estate than to the thread ID. Also, the thread ID is fixed for each thread, whereas we could add different text to each prompt to make each one more self-describing. But in general, I see no significant difference between these two alternatives, because they both add some text to the prompt.