From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 30458 invoked from network); 21 Aug 2020 14:20:40 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 21 Aug 2020 14:20:40 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1k97te-008sVh-E4; Fri, 21 Aug 2020 09:19:58 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1k97tZ-008sTp-Vt for ding@lists.math.uh.edu; Fri, 21 Aug 2020 09:19:54 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1k97tW-00F2n8-LV for ding@lists.math.uh.edu; Fri, 21 Aug 2020 09:19:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eVAMOJBmbBFWkjPPZHVww9CZP3OAWLWuc/Ggev3g11w=; b=EIyaebCYO0TEG9K2SVC+JLQKE2 CuJ1qT5G1vdWNrCeGotoLYIhJCWy52cNWvbG8NPn8r63w0V2u+bizPs71velPw5WF0o80UUnIU27X j9obEx4rzEs6xZTeWSQzJYUYJASXKyPWzSXWfwPvzqEYE3OQ8FV4gug4vP3fe8yzf4b0=; Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214] helo=ciao.gmane.io) by quimby with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k97tP-0005XY-U4 for ding@gnus.org; Fri, 21 Aug 2020 16:19:46 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1k97tN-000ABi-44 for ding@gnus.org; Fri, 21 Aug 2020 16:19:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Wayne Harris Subject: Re: is there a possibility for gnus to download data without blocking? Date: Fri, 21 Aug 2020 11:18:56 -0300 Message-ID: <868se8gjzj.fsf@protonmail.com> References: <86y2m8hccw.fsf@protonmail.com> <87imdcvchr.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Cancel-Lock: sha1:4ya//SSfIwl492y2jOCfCrkP0GY= List-ID: Precedence: bulk Eric Abrahamsen writes: > Wayne Harris writes: > >> Is there a possibility for gnus to download data without blocking? >> Wouldn't it be nice to be able to keep using EMACS while Gnus is >> downloading? >> >> Is it a limitation of EMACS itself? If so, is there any plans for >> supporting such things in the future? Wouldn't it be nice? > > It would be lovely! There are a few issues: Emacs is single-threaded, > though it has the ability to continue execution while waiting on IO from > an external process. So theoretically we can already "download data > without blocking". In fact, Gnus already does this in a limited way: > when you hit "g", it starts an async external process for each of your > servers (each that involves an external process, anyway), then polls > each one until they're all done, and then continues with updating its > state. The fact that it uses external processes seems totally acceptable and perhaps even desirable. I like external processes. That means I could look at that part of the system individually using my shell. > That means there's really only a benefit when you have multiple servers > that can overlap their IO, and you're still going to wait as long as the > longest server takes. Interesting. I haven't noticed that. For example, when I say ``A A'' on the group buffer to fetch a list of all groups, I see each news server being read one after the other. But you didn't say this should have happened. You said when I say ``g'' and I can't really tell what happens when I say ``g'', so I'll believe you. > In theory we could have a Gnus that fires off all the servers and then > returns control to the user immediately, but that would involve handling > out-of-band returns as they came in from the servers, and Gnus would > have to be structured very differently than it is now to manage that. I don't expect ever to be able to download a bunch of data and have it all very fast on my screen. But I do think that a system being always faster than the user gives the user an impression of total control, which is pleasurable. So I would consider that a very nice improvement for Gnus itself. And for EMACS, I can't see the need for anything else because if it can poll on external processes, that is powerful enough for anything I could think of.