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: Fri, 31 Aug 2018 21:17:37 +0300 Message-ID: <834lfa2yf2.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> <23431.17784.483000.193228@gargle.gargle.HOWL> <83zhx40zum.fsf@gnu.org> <23432.24003.789000.471856@gargle.gargle.HOWL> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535739657 7282 195.159.176.226 (31 Aug 2018 18:20:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2018 18:20:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Uday Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 31 20:20:52 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 1fvo2O-0001o2-RB for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 20:20:52 +0200 Original-Received: from localhost ([::1]:56137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvo4U-0000BR-Sr for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 14:23:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvnzW-0004ev-Lh for emacs-devel@gnu.org; Fri, 31 Aug 2018 14:17:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvnzU-0006x2-18 for emacs-devel@gnu.org; Fri, 31 Aug 2018 14:17:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvnzT-0006wy-TB; Fri, 31 Aug 2018 14:17:51 -0400 Original-Received: from [176.228.60.248] (port=2612 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvnzT-0000vp-GW; Fri, 31 Aug 2018 14:17:51 -0400 In-reply-to: <23432.24003.789000.471856@gargle.gargle.HOWL> (message from Uday Reddy on Thu, 30 Aug 2018 22:12:35 +0100) 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:229145 Archived-At: > Date: Thu, 30 Aug 2018 22:12:35 +0100 > From: Uday Reddy > Cc: Uday S Reddy , > emacs-devel@gnu.org > > Put the entire Gnus into a thread? That sounds rather ambitious. And yet this is one of the first things people tried as soon as concurrency landed on the master branch. > But, more to the point, I don't see what purpose it serves. That Gnus thread > will hang while it is downloading news and the user is left twiddling his > thumbs. Threads can only be useful if Gnus is *modified* to relegate the > network activity to background threads, so that Gnus itself remains > responsive. That can only be achieved if Gnus is purposely rewritten for > that purpose. No free lunch. Not so: since Gnus reads the newsgroups by using APIs like accept-process-output, the user could still do something useful while Gnus waits for the server to respond. IOW, reading newsgroups is a series of calls that accept stuff from the server, and the thread infrastructure lets the main thread kick in between the calls. > The effect of a "Gnus thread" can already be achieved by just starting a > separate Emacs session for Gnus. Why bother with threads just to replicate > the same behaviour? Because (a) you don't need another process, and (b) you can start reading the new messages before Gnus is done downloading everything. IOW, exactly for the same reasons it is better to run "M-x compile" asynchronously instead of in another Emacs session. > Think of ELPA. You fill out a huge form telling it everything you want it to > do. Then it goes off and does it. No quesitons asked. I think this will be a small subset of what people want to do without locking up Emacs. Many Lisp programs do most of its job silently, but do need to ask a question or two from time to time. There's no need to give up on running such jobs on non-main threads. > You seem to want "foreground threads", which handle buffers and frames etc. > to do one kind of activity the user is wanting to do. Correction: it's not me, it's Emacs users and programmers. Case in point: the feature/tramp-thread-safe branch. It is not a coincidence that the very first serious attempt to use the concurrency feature bumped at these issues almost immediately.