From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Thu, 30 Aug 2018 02:16:40 +0100 Message-ID: <23431.17784.483000.193228@gargle.gargle.HOWL> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1535591689 2750 195.159.176.226 (30 Aug 2018 01:14:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2018 01:14:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 03:14:44 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 1fvBXo-0000ad-LR for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2018 03:14:44 +0200 Original-Received: from localhost ([::1]:46214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvBZu-0006um-Vj for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 21:16:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvBZo-0006uH-4C for emacs-devel@gnu.org; Wed, 29 Aug 2018 21:16:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvBZj-00021e-5F for emacs-devel@gnu.org; Wed, 29 Aug 2018 21:16:48 -0400 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]:60196) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fvBZi-00020s-Tu; Wed, 29 Aug 2018 21:16:43 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fvBZh-0007JM-OL; Thu, 30 Aug 2018 02:16:41 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk (envelope-from ) with esmtp (Exim 4.90_1) id 1fvBZh-0005Uq-EI using interface smart1.bham.ac.uk; Thu, 30 Aug 2018 02:16:41 +0100 Original-Received: from cca-132309.cs.bham.ac.uk ([147.188.193.190]) by mx1.cs.bham.ac.uk with esmtp (Exim 4.90_1) (envelope-from ) id 1fvBRt-0006Aw-K1; Thu, 30 Aug 2018 02:08:37 +0100 In-Reply-To: <83va7x5guc.fsf@gnu.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-mingw32) X-BHAM-SendViaRouter: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 147.188.128.137 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:229080 Archived-At: Eli Zaretskii writes: > As a trivial example, consider 2 threads, one copying files, the other > removing files. How do you know whether to confirm or not when the prompt > says just "FOO (y or n)?" At a minimum, the elisp coder would have to give fuller prompts, e.g., copy FOO (y or n)? remove FOO (y or n)? But still it is dangerous. If a "remove FOO?" prompt comes in the middle of a series of "copy FOO?" prompts, the user is not going to notice that the context has changed. The best solution is to lock the user interaction until all the prompts of one kind are done. > 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. In my view, the non-main threads asking for user interaction should be a rarity. Ideally, the main thread should do all the interaction that is necessary, and then spawn the sub-threads with all the information they need. It is easy for us to generate a hundred threads. But it is not possible for the user to create a hundred threads in their own head. So, yes, the user is going to cut down the concurrency. Cheers, Uday