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: Wed, 22 Aug 2018 17:28:01 +0300 Message-ID: <837ekicw7i.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534947977 18752 195.159.176.226 (22 Aug 2018 14:26:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2018 14:26:17 +0000 (UTC) Cc: psainty@orcon.net.nz, gazally@runbox.com, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 16:26:12 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 1fsU5L-0004jC-HV for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 16:26:11 +0200 Original-Received: from localhost ([::1]:59294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsU7Q-0002dS-VH for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 10:28:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsU7J-0002d8-78 for emacs-devel@gnu.org; Wed, 22 Aug 2018 10:28:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsU7F-0007rX-VG for emacs-devel@gnu.org; Wed, 22 Aug 2018 10:28:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsU7F-0007r2-N6; Wed, 22 Aug 2018 10:28:09 -0400 Original-Received: from [176.228.60.248] (port=3044 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fsU76-0007tX-L8; Wed, 22 Aug 2018 10:28:01 -0400 In-reply-to: (message from Richard Stallman on Wed, 22 Aug 2018 00:05:58 -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:228810 Archived-At: > From: Richard Stallman > Cc: psainty@orcon.net.nz, gazally@runbox.com, > emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, > emacs-devel@gnu.org > Date: Wed, 22 Aug 2018 00:05:58 -0400 > > Is it necessary to support user interaction from multiple threads > on any given terminal? If not necessary, is it worth the trouble? IMO, it is worth the trouble. If we don't provide a way of coping with that, the concurrency feature will be much less useful than it could have been, because only a very limited class of Lisp programs will be able to run in non-main threads. The case in point is Michael's work on the tramp-thread-safe branch: there' visiting files and other file-related commands run in another thread (useful for commands that take a lot of time to complete, such as accessing remote files via Tramp). The code does it by running normal file primitives in separate threads. However, some primitives and subroutines need to ask the user something, such as whether to apply file-local variables that might be unsafe, and need the user to respond. If we decide that user interaction from other threads is "verboten", it means all such mundane operations, of which we have gazillions in Emacs, suddenly become impossible to use in a program that could run in another thread, and then what do we expect Lisp programmers to do about that? invent a whole new set of parallel functions that somehow avoid asking such questions or prompting the user when they need to? IOW, limiting user interaction to a single thread will in practice allow running in other threads only programs that never interact with the user, such as some batch-style mathematical calculation or text processing. Most Emacs Lisp programs are not like that. The whole point of introducing threads was to allow running code asynchronously with minimum fuss. If it turns out that the amount of fuss is much larger than that, then we gained nothing, because we can already run "asynchronous" code from timers and process filters, given enough effort to make a program abide by the rules necessary to work in such situations. > If it is ok not to support that, maybe we should take a different > approach, such as assigning any given terminal to one thread. Unless I misunderstand what you mean by "given terminal", doing that won't solve the hard part of the problem: how to multiplex input events between different threads which require user attention simultaneously. That's because, AFAIR, even with multiple displays, we still serialize input: once I start typing a key sequence on one display, the others won't accept any input until I finish.