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=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4063 invoked from network); 21 Aug 2020 04:40:19 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 21 Aug 2020 04:40:19 -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 1k8yqK-008nND-Uh; Thu, 20 Aug 2020 23:39:56 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1k8yqG-008nLG-CJ for ding@lists.math.uh.edu; Thu, 20 Aug 2020 23:39:52 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1k8yqE-00F3NH-Jo for ding@lists.math.uh.edu; Thu, 20 Aug 2020 23:39:52 -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=FT4233FuvHuSuTmeIos7qYrv8cb2QtdqNOVUJua0y04=; b=m9JEaCawBiP8gHHS49Dc22Bxe6 z/EILbrlWb/MTKzedY0Gzz4inO9x3eAb/RCpfWzQb8qJZibF1t76A39QBkEMTAupnUzmirFo4rzq1 oStCxaUcQjwRwcIz8q6DHsd+JiR0HjVSs/H+IyY+jZTSQp30UplGoin9T7E3pC7uTZiA=; 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 1k8yq7-0007FP-8w for ding@gnus.org; Fri, 21 Aug 2020 06:39:46 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1k8yq6-0001iY-6e for ding@gnus.org; Fri, 21 Aug 2020 06:39:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: is there a possibility for gnus to download data without blocking? Date: Thu, 20 Aug 2020 21:39:28 -0700 Message-ID: <87imdcvchr.fsf@ericabrahamsen.net> References: <86y2m8hccw.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:rtZ6Cz8CiPvvPNTb2wOIo/X7xj0= List-ID: Precedence: bulk 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. 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. 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. Eric