From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4561 Path: main.gmane.org!not-for-mail From: Patrick Audley Newsgroups: gmane.emacs.gnus.general Subject: Getting articles asynchronously..... Date: Tue, 26 Dec 95 01:16:06 -0800 Message-ID: <9512260916.AA0169@localhost> Reply-To: paudley@portal.ca NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145292 30086 80.91.224.250 (20 Oct 2002 20:21:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:32 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id CAA25925 for ; Tue, 26 Dec 1995 02:32:15 -0800 Original-Received: from kefron.portal.ca (root@kefron.portal.ca [205.206.104.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 26 Dec 1995 11:05:06 +0100 Original-Received: from d219.portal.ca (d219.portal.ca [205.206.104.219]) by kefron.portal.ca (8.6.12/8.6.12) with SMTP id CAA20725; Tue, 26 Dec 1995 02:04:10 -0800 Original-Received: by localhost (IBM OS/2 SENDMAIL VERSION 1.3.9)/1.0um) id AA0169; Tue, 26 Dec 95 01:16:06 -0800 Original-To: -Ding- Gnus Mailing List Precedence: first-class X-Emacs: GNU Emacs 19.30.1 i486 OS/2 Warp X-Mailer: September Gnus v0.26 BBDB version 1.50; 18-feb-94. X-Pgp-Fingerprint: C7 CD D9 67 74 BF 70 E5 98 91 EA 7D FB 47 EF A7 X-Spook: NSA Honduras North Korea Ft. Meade Qaddafi colonel Uzi Kennedy X-Url: InterNet Portal Xref: main.gmane.org gmane.emacs.gnus.general:4561 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4561 Since it is possible to fetch the next article asynchronously while reading an article, is there a way to make gnus fetch all articles in the background. This way, one could select all the binaries in, say, comp.binaries.os2 and hit "X U" then go on one's merry way, emacsing as usual while Gnus fetches and uudecodes all my spiffy new utilities ;) -- ... Putting your best foot forward at least keeps it out of your mouth. -Morris Mandel in _The Jewish Press_ /*----------------------------------------------------------------. | The Crystal Wind is The Storm, Patrick Audley | | The Storm is The Data, ______/\/\/\/\/\/\/\_______ | | The Data is Life. InterNet: paudley@portal.ca | `---[OS/2]--[Anime]-[Trance]-[C++]-------------------------------*/ From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4562 Path: main.gmane.org!not-for-mail From: Stainless Steel Rat Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Tue, 26 Dec 1995 09:18:28 -0500 Organization: The Happy Fun Ball Brigade Message-ID: <199512261418.JAA17643@delphi.ccs.neu.edu> References: <9512260916.AA0169@localhost> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145293 30089 80.91.224.250 (20 Oct 2002 20:21:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:33 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id GAA26029 for ; Tue, 26 Dec 1995 06:47:09 -0800 Original-Received: from amber.ccs.neu.edu (root@amber.ccs.neu.edu [129.10.111.100]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 26 Dec 1995 15:18:31 +0100 Original-Received: from delphi.ccs.neu.edu (ratinox@delphi.ccs.neu.edu [129.10.112.101]) by amber.ccs.neu.edu (8.7.1/8.7.1) with ESMTP id JAA17555 for ; Tue, 26 Dec 1995 09:18:29 -0500 (EST) Original-Received: (ratinox@localhost) by delphi.ccs.neu.edu (8.6.12/8.6.4) id JAA17643; Tue, 26 Dec 1995 09:18:28 -0500 Original-To: "(ding) Gnus Mailing List" In-reply-to: Patrick Audley's message of Tue, 26 Dec 95 01:16:06 -0800 X-NSA-Fodder: security Khaddafi Peking terrorist arrangements X-Attribution: Rat Xref: main.gmane.org gmane.emacs.gnus.general:4562 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4562 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "PA" == Patrick Audley writes: PA> Since it is possible to fetch the next article asynchronously while PA> reading an article, is there a way to make gnus fetch all articles PA> in the background. That is an exceedingly bad plan in large newsgroups or groups with large articles, such as source or binaries newsgroups. Emacs will run out of memory before it's finished pre-fetching. PA> as usual while Gnus fetches and uudecodes all my spiffy new PA> utilities ;) That would require a multithreaded Emacs kernel, something that a) does not exist and, b) likely won't exist for quite some time. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMOAELJ6VRH7BJMxHAQEE8QQAlfHC26AEaoxXyVk6hShByOcL+1NXS8P1 lTRJt5+56fq6UKN8bIzrZjTOvMZM/md5mFWGvaX5GFWObB27L4aIiUPJHW4BxJGj WfSjiLjT0/GzvaGhhHONeO/tgEVioaTzADcRu64gVJB8SJCPvNQjJjafe1Xly/OQ KV56VDXtEkQ= =hdl1 -----END PGP SIGNATURE----- -- Rat \ Warning: pregnant women, the elderly, and PGP Public Key: Ask for one today! \ children under 10 should avoid prolonged http://www.ccs.neu.edu/home/ratinox/ \ exposure to Happy Fun Ball. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4563 Path: main.gmane.org!not-for-mail From: Patrick Audley Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 26 Dec 1995 12:57:36 -0800 Organization: Portal To The InterNet Sender: paudley@Black-Lightning.portal.ca Message-ID: References: <9512260916.AA0169@localhost> <199512261418.JAA17643@delphi.ccs.neu.edu> Reply-To: paudley@portal.ca NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145294 30090 80.91.224.250 (20 Oct 2002 20:21:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:34 +0000 (UTC) Cc: -Ding- Gnus Mailing List Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id NAA27603 for ; Tue, 26 Dec 1995 13:49:25 -0800 Original-Received: from kefron.portal.ca (root@kefron.portal.ca [205.206.104.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 26 Dec 1995 22:21:02 +0100 Original-Received: from d237.portal.ca (d237.portal.ca [205.206.104.237]) by kefron.portal.ca (8.6.12/8.6.12) with SMTP id NAA16116; Tue, 26 Dec 1995 13:20:03 -0800 Original-Received: by localhost (IBM OS/2 SENDMAIL VERSION 1.3.9)/1.0um) id AA0057; Tue, 26 Dec 95 12:57:49 -0800 Original-To: Stainless Steel Rat Precedence: first-class X-Emacs: GNU Emacs 19.30.1 i486 OS/2 Warp X-Mailer: September Gnus v0.26; nnml 1.0; nnmh 1.0 BBDB version 1.50; 18-feb-94. X-Pgp-Fingerprint: C7 CD D9 67 74 BF 70 E5 98 91 EA 7D FB 47 EF A7 X-Spook: KGB Croatian SDI BATF North Korea Cocaine Rule Psix terrorist X-Url: InterNet Portal In-Reply-To: Stainless Steel Rat's message of Tue, 26 Dec 1995 09:18:28 -0500 Original-Lines: 38 Xref: main.gmane.org gmane.emacs.gnus.general:4563 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4563 >>>>> "Rat" == Stainless Steel Rat writes: >>>>> "PA" == Patrick Audley writes: Rat> That is an exceedingly bad plan in large newsgroups or groups Rat> with large articles, such as source or binaries newsgroups. Rat> Emacs will run out of memory before it's finished pre-fetching. No, No... I didn't mean that Gnus should fetch articles arbitrarily. Here's an example... Imagine you're on a slow connection (say.. 28.8) and you're browsing you're favorite binaries group. You see a great program that you just have to have, so you mark all the uuencoded parts and hit "XU". And wait... And Wait... And Wait. Since Gnus can already fetch articles in the background (I assume this is what gnus-asynchronous toggles), is there not a way to do all fetching in the background. The TCP process that connects to the NNTP server (at least under OS/2) is running as a separate process, could it not spool all the information into a buffer and notify Gnus when it was done? Rat> That would require a multithreaded Emacs kernel, something that Rat> a) does not exist and, b) likely won't exist for quite some time. I know that at least some of this is possible now, for instance, start up a (shell) and execute some _LONG_ task, say zipping 20M of text or something. Switch to another window, and the shell keeps feeding output to the *Shell* buffer, while you're doing other things. -- ... They laughed at Edison and Einstein, but somehow I still feel uncomfortable when they laugh at me. -Ashleigh Brilliant (_Pot Shots_) /*----------------------------------------------------------------. | The Crystal Wind is The Storm, Patrick Audley | | The Storm is The Data, ______/\/\/\/\/\/\/\_______ | | The Data is Life. InterNet: paudley@portal.ca | `---[OS/2]--[Anime]-[Trance]-[C++]-------------------------------*/ From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4564 Path: main.gmane.org!not-for-mail From: Stainless Steel Rat Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Tue, 26 Dec 1995 18:34:06 -0500 Organization: The Happy Fun Ball Brigade Message-ID: <199512262334.SAA24254@delphi.ccs.neu.edu> References: <9512260916.AA0169@localhost> <199512261418.JAA17643@delphi.ccs.neu.edu> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145294 30091 80.91.224.250 (20 Oct 2002 20:21:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:34 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id PAA28256 for ; Tue, 26 Dec 1995 15:58:43 -0800 Original-Received: from amber.ccs.neu.edu (root@amber.ccs.neu.edu [129.10.111.100]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 27 Dec 1995 00:34:08 +0100 Original-Received: from delphi.ccs.neu.edu (ratinox@delphi.ccs.neu.edu [129.10.112.101]) by amber.ccs.neu.edu (8.7.1/8.7.1) with ESMTP id SAA23979 for ; Tue, 26 Dec 1995 18:34:07 -0500 (EST) Original-Received: (ratinox@localhost) by delphi.ccs.neu.edu (8.6.12/8.6.4) id SAA24254; Tue, 26 Dec 1995 18:34:06 -0500 Original-To: "(ding) Gnus Mailing List" In-reply-to: Patrick Audley's message of 26 Dec 1995 12:57:36 -0800 X-NSA-Fodder: fissionable munitions SEAL Team 6 spy arrangements X-Attribution: Rat Xref: main.gmane.org gmane.emacs.gnus.general:4564 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4564 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "PA" == Patrick Audley writes: PA> Since Gnus can already fetch articles in the background Actually, it doesn't. The asynchronous article fetch occours when Emacs isn't doing anything else. Ie, it is multitasking, not multithreading, just like an inferior shell process. Inferior shells are the same: the inferior process (shell, TCP/IP connection, whatever) is chugging along independant of Emacs, spitting output through whatever (interrupt driver like) process handler has been set up. What you are asking is to have Emacs do two things at once: process marked articles and read more news. Neither of these are handled in inferior processes. In short, Emacs just can't do it because it isn't threaded. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMOCGZp6VRH7BJMxHAQHOfAP/dEd/BxsGYYe1nwszW/ID55rGjwh41Htm GaAbuyuJNl9n/luI1iuArf22esMx4QhVE6bo4+esje+6VL0TPcvpobESmRrbyqma 7nm6o5EAusg9ZPpPMQWD48nscQiZX+iebDGzT9J+mzCgx1IIzL1fogk9GyhJOs3R 5GcCZBr5u24= =aRCT -----END PGP SIGNATURE----- -- Rat \ Do not use Happy Fun Ball on concrete. PGP Public Key: Ask for one today! \ http://www.ccs.neu.edu/home/ratinox/ \ From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4565 Path: main.gmane.org!not-for-mail From: Felix Lee Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Tue, 26 Dec 1995 17:18:59 -0800 Message-ID: <199512270119.RAA22034@desiree.teleport.com> References: <199512261418.JAA17643@delphi.ccs.neu.edu> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145295 30092 80.91.224.250 (20 Oct 2002 20:21:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:35 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id RAA31139 for ; Tue, 26 Dec 1995 17:43:48 -0800 Original-Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 27 Dec 1995 02:19:06 +0100 Original-Received: from teleport.com (ip-pdx10-30.teleport.com [206.163.122.94]) by desiree.teleport.com (8.6.12/8.6.9) with ESMTP id RAA22034 for ; Tue, 26 Dec 1995 17:19:02 -0800 Original-To: "(ding) Gnus Mailing List" In-reply-to: Your message of Tue, 26 Dec 1995 09:18:28 EST. <199512261418.JAA17643@delphi.ccs.neu.edu> Xref: main.gmane.org gmane.emacs.gnus.general:4565 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4565 > That is an exceedingly bad plan in large newsgroups or groups with large > articles, such as source or binaries newsgroups. Emacs will run out of > memory before it's finished pre-fetching. well, you pre-fetch to disk, rather than to memory. > That would require a multithreaded Emacs kernel, something that a) does > not exist and, b) likely won't exist for quite some time. you can do most of the job by running subprocesses. a caching nntp proxy could take care of asynchronous article fetching. once you have that, gnus just needs to add a "maybe-it-would-be-a-good-idea- to-prefetch-this" entry point to its backend interface. (async article fetching is on my wishlist-that-I-might-actually-do- something-about, because "Free Agent" (a Windoze newsreader my boyfriend uses) is actually much nicer than gnus over a ppp link. and there's no way I'm going to run Windoze to use a newsreader.) -- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4566 Path: main.gmane.org!not-for-mail From: "Mark W. Eichin" Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Wed, 27 Dec 1995 23:53:52 -0500 Message-ID: <199512280453.XAA00789@perdiem.cygnus.com> References: <199512261418.JAA17643@delphi.ccs.neu.edu> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145296 30097 80.91.224.250 (20 Oct 2002 20:21:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:36 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id VAA07390 for ; Wed, 27 Dec 1995 21:25:35 -0800 Original-Received: from cygnus.com (cygnus.com [140.174.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 28 Dec 1995 05:55:14 +0100 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id UAA12305; Wed, 27 Dec 1995 20:55:07 -0800 Original-Received: by tweedledumb.cygnus.com (4.1/4.7) id AA24638; Wed, 27 Dec 95 23:55:05 EST Original-Received: by perdiem.cygnus.com (8.6.12/4.7) id XAA00789; Wed, 27 Dec 1995 23:53:52 -0500 Original-To: ratinox@ccs.neu.edu In-Reply-To: <199512261418.JAA17643@delphi.ccs.neu.edu> (message from Stainless Steel Rat on Tue, 26 Dec 1995 09:18:28 -0500) Xref: main.gmane.org gmane.emacs.gnus.general:4566 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4566 > That would require a multithreaded Emacs kernel, something that a) does > not exist and, b) likely won't exist for quite some time. Actually, I've heard that some progress has been made integrating pthreads into guile, and an emacs that uses guile (either with or instead of elisp) is a likely next step, so "quite some time" may be a matter of months... _Mark_ Cygnus Support, Eastern USA From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4567 Path: main.gmane.org!not-for-mail From: gsstark@MIT.EDU (Greg Stark) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 28 Dec 1995 08:35:12 -0500 Organization: Massachvsetts Institvte of Technology Sender: gsstark@fierce-bad-rabbit.MIT.EDU Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145297 30101 80.91.224.250 (20 Oct 2002 20:21:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:37 +0000 (UTC) Cc: ratinox@ccs.neu.edu, ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from moonbase_v.moonvalley.com (moonbase_v.moonvalley.com [204.212.162.1]) by miranova.com (8.6.11/8.6.9) with ESMTP id FAA08933 for ; Thu, 28 Dec 1995 05:58:33 -0800 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by moonbase_v.moonvalley.com (8.6.12/8.6.9) with ESMTP id FAA21971 for ; Thu, 28 Dec 1995 05:48:07 -0800 Original-Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 28 Dec 1995 14:35:22 +0100 Original-Received: from FIERCE-BAD-RABBIT.MIT.EDU by MIT.EDU with SMTP id AA27462; Thu, 28 Dec 95 08:35:06 EST Original-Received: by fierce-bad-rabbit.MIT.EDU (5.57/4.7) id AA00344; Thu, 28 Dec 95 08:35:14 -0500 Original-To: "Mark W. Eichin" In-Reply-To: "Mark W. Eichin"'s message of Wed, 27 Dec 1995 23:53:52 -0500 Original-Lines: 54 Xref: main.gmane.org gmane.emacs.gnus.general:4567 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4567 Actually, I was just in the process of writing a back end, and it occurred to me I was taking an essentially asynchronous operation (interacting with a subprocess) and serializing it. This is an enormous lose, an existing interface allows users to start an operation and go work on other things; it does this by putting most of the work in the filter function. The basic design to make Gnus do this would be to split each of the backend interface functions into two steps. Gnus would call a normal looking backend function, but would pass a couple extra arguments. One of the extra arguments would be a function the backend function would call when it finshed its processing. I think it would also be useful to pass a nonce along as well and pass it back to Gnus. I would have said this would be very difficult to get right, but I also would have said that about a lot of existing Gnus features. And in my opinion this is the key feature that would make Gnus a lot more useful. I do a lot of things in my Emacs and it frustrates me when it freezes for more than a few seconds. In fact, I think the least robust part of my backend is going to be the joining of the synchronous backend interface and the asynchronous sub-process. It would be easier to implement robustly if both were asynchronous. greg In case I wasn't clear here's an example of what I mean: (defun nnchoke-retrieve-headers (articles call-back nonce &optional g s f) (start-process foo ...) (set-process-filter foo 'nnchoke-retrieve-headers-do-work) 'in-progress) (defun nnchoke-retrieve-headers-do-work (p s) ... process a lot of data but without blocking Emacs ... (funcall call-back nonce 'nov)) obviously some parts of the api need to be fixed to handle this, The nntp-server-buffer must either be passed down or dynamically bound. The concept of a ``current group'' should probably be given up. things like that, but nothing terribly major. (except that i don't think the above example works because of the scoping of call-back and nonce, hmm) greg From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4588 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 03 Jan 1996 10:20:06 +0100 Organization: Xmas Exiles Sender: larsi@bjob.no Message-ID: <20phy6rd.fsf@bjob.no> References: <199512270119.RAA22034@desiree.teleport.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035145315 30179 80.91.224.250 (20 Oct 2002 20:21:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:21:55 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id JAA00687 for ; Sat, 6 Jan 1996 09:41:39 -0800 Original-Received: from Norway.EU.net (nic.eunet.no [193.71.1.1]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 6 Jan 1996 18:00:48 +0100 Original-Received: by Norway.EU.net with UUCP id AA23222 (5.65c/IDA-1.4.4/EUnet/NO for ding@ifi.uio.no); Sat, 6 Jan 1996 18:00:45 +0100 Original-Received: (from larsi@localhost) by redleaf.bbs.no (8.6.12/8.6.9) id KAA24276; Sat, 6 Jan 1996 10:16:21 GMT Original-To: ding@ifi.uio.no In-Reply-To: Felix Lee's message of Tue, 26 Dec 1995 17:18:59 -0800 Original-Lines: 37 Xref: main.gmane.org gmane.emacs.gnus.general:4588 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4588 Felix Lee writes: > > That would require a multithreaded Emacs kernel, something that a) does > > not exist and, b) likely won't exist for quite some time. > > you can do most of the job by running subprocesses. a caching nntp > proxy could take care of asynchronous article fetching. once you have > that, gnus just needs to add a "maybe-it-would-be-a-good-idea- > to-prefetch-this" entry point to its backend interface. Howzabout an "asynchronous cache"? I mean, you press a magic key on (say) a group, and then Gnus starts fetching the (unread) articles in the group asynchronously and puts them all in the cache as they arrive. The user would typically do something else than wait for the cache to fill up -- read mail, or whatver. (If you have a slow disk, this will mean that Emacs would become more sluggish since most of the time would be spent in `write-region' calls in the "asynchronous" part of the code, which would basically be filters that sniffs the output from the tcp process.) Then, uhm, when you enter the group all the articles are read from disk, as usual when using the cache. ... perhaps one could have "postponed commands"? Process-mark a few articles, press a magic "postpone" key and then `X U', and Gnus would do the asynchronous cache thing on the process-marked articles, and the execute the `X U' when all the articles have arrived in the cache. Or whatever. I don't think this would be extremely much work, actually. It would be pretty localized and would rely on the already established cache mechanisms. -- Lars Magne Ingebrigtsen * larsi@ifi.uio.no (a red leaf that falls from the purple tree) From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4688 Path: main.gmane.org!not-for-mail From: gsstark@MIT.EDU (Greg Stark) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 15 Jan 1996 04:15:52 -0500 Organization: Massachvsetts Institvte of Technology Sender: gsstark@fierce-bad-rabbit.MIT.EDU Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145401 30499 80.91.224.250 (20 Oct 2002 20:23:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:23:21 +0000 (UTC) Cc: "Mark W. Eichin" , ratinox@ccs.neu.edu, ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id BAA08287 for ; Mon, 15 Jan 1996 01:53:25 -0800 Original-Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 15 Jan 1996 10:16:04 +0100 Original-Received: from FIERCE-BAD-RABBIT.MIT.EDU by MIT.EDU with SMTP id AA11920; Mon, 15 Jan 96 04:15:48 EST Original-Received: by fierce-bad-rabbit.MIT.EDU (5.57/4.7) id AA10754; Mon, 15 Jan 96 04:15:54 -0500 Original-To: gsstark@MIT.EDU (Greg Stark) In-Reply-To: gsstark@MIT.EDU's message of 28 Dec 1995 08:35:12 -0500 Original-Lines: 88 Xref: main.gmane.org gmane.emacs.gnus.general:4688 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4688 Hmm, having thought about this a bit more it seems to me that the right design is a little subtler than I described. Instead specific functions could be made optionally asynchronous in a backwards compatible manner by having a valid return value be something of the form '(in-progess nonce) where nonce would be something returned by gnus-make-nonce. Then those specific functions would have corresponding call-back functions that the backend would be expected to call when they completed or in some cases when even some of the data was ready. So for example if gnus called nnchoke-retrieve-headers then nnchoke would return (list ('in-progress (gnus-make-nonce))) and set the filter function on its process or network stream to something that would call gnus-callback-retrieve-headers with the resultant data and the returned value (which would include the nonce so gnus would know what operation had just completed). A few notes, some things like the use of a single buffer for backends to put the resulting data in would have to be fixed, since as long as there's a pending operation on one buffer gnus would have to be careful not to reuse that buffer. Also, it would be nice if Gnus also provided some callbacks for processing partial results, instead of having to fetch all the data then process it all. There's a lot of idle time when fetching data that the processor could be busy processing the data it has already. There's a lot of real gains to be made here. Gnus would be a lot more useful if it didn't lock up Emacs while doing long operations like listing groups, checking for bogus groups, or entering a group (once took me over 30 minutes). And it can be faster if it didn't inneffiently wait for all the data to arrive, perhaps over a slow connection, before trying to process any of it. greg > Actually, I was just in the process of writing a back end, and it occurred > to me I was taking an essentially asynchronous operation (interacting with > a subprocess) and serializing it. > > This is an enormous lose, an existing interface allows users to start an > operation and go work on other things; it does this by putting most of the > work in the filter function. > > The basic design to make Gnus do this would be to split each of the backend > interface functions into two steps. Gnus would call a normal looking backend > function, but would pass a couple extra arguments. One of the extra arguments > would be a function the backend function would call when it finshed its > processing. I think it would also be useful to pass a nonce along as well and > pass it back to Gnus. > > I would have said this would be very difficult to get right, but I also would > have said that about a lot of existing Gnus features. And in my opinion this > is the key feature that would make Gnus a lot more useful. I do a lot of > things in my Emacs and it frustrates me when it freezes for more than a few > seconds. > > In fact, I think the least robust part of my backend is going to be the > joining of the synchronous backend interface and the asynchronous sub-process. > It would be easier to implement robustly if both were asynchronous. > > greg > > > > > In case I wasn't clear here's an example of what I mean: > > (defun nnchoke-retrieve-headers (articles call-back nonce &optional g s f) > (start-process foo ...) > (set-process-filter foo 'nnchoke-retrieve-headers-do-work) > 'in-progress) > > (defun nnchoke-retrieve-headers-do-work (p s) > ... > process a lot of data > but without blocking Emacs > ... > (funcall call-back nonce 'nov)) > > > obviously some parts of the api need to be fixed to handle this, > The nntp-server-buffer must either be passed down or dynamically bound. > The concept of a ``current group'' should probably be given up. > things like that, but nothing terribly major. > (except that i don't think the above example works because of the scoping of > call-back and nonce, hmm) > > greg > From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4698 Path: main.gmane.org!not-for-mail From: Steven L Baur Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 15 Jan 1996 12:36:44 -0800 Organization: Miranova Systems, Inc. Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.38) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035145409 30523 80.91.224.250 (20 Oct 2002 20:23:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:23:29 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id NAA11710 for ; Mon, 15 Jan 1996 13:18:46 -0800 Original-Received: from miranova.com (steve@miranova.com [204.212.162.100]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 15 Jan 1996 21:39:33 +0100 Original-Received: (from steve@localhost) by miranova.com (8.7.3/8.6.9) id MAA11394; Mon, 15 Jan 1996 12:36:47 -0800 Original-To: ding@ifi.uio.no X-Url: http://www.miranova.com/%7Esteve/ In-Reply-To: gsstark@MIT.EDU's message of 15 Jan 1996 01:15:52 -0800 Original-Lines: 15 X-Mailer: September Gnus v0.26/XEmacs 19.13 Xref: main.gmane.org gmane.emacs.gnus.general:4698 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4698 >>>>> "Greg" == Greg Stark writes: Greg> There's a lot of real gains to be made here. Gnus would be a Greg> lot more useful if it didn't lock up Emacs while doing long Greg> operations like listing groups, checking for bogus groups, or Greg> entering a group (once took me over 30 minutes). It's making less and less sense to me to have Gnus wait while reading the NNTP active file at startup, with mail to be read and such. Could the active file be read by a subprocess similar to the exmh-bg mailchecker in exmh? -- steve@miranova.com baur From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4718 Path: main.gmane.org!not-for-mail From: Ketil Z Malde Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Tue, 16 Jan 1996 11:34:02 +0100 Message-ID: <9601161034.AA07122@krone.ii.uib.no> References: <199512280453.XAA00789@perdiem.cygnus.com> Reply-To: ketil@ii.uib.no NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145425 30567 80.91.224.250 (20 Oct 2002 20:23:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:23:45 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id DAA20726 for ; Tue, 16 Jan 1996 03:22:18 -0800 Original-Received: from eik (eik.ii.uib.no [129.177.16.3]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 16 Jan 1996 11:34:04 +0100 Original-Received: from krone.ii.uib.no (krone) by eik with SMTP id AA05499 (5.67b/IDA-1.5 for ding@ifi.uio.no); Tue, 16 Jan 1996 11:34:03 +0100 Original-Received: by krone.ii.uib.no; (5.65v3.2/1.1.8.2/30Jun95-0539PM) id AA07122; Tue, 16 Jan 1996 11:34:02 +0100 Original-To: Steven L Baur In-Reply-To: Steven L Baur's message of 15 Jan 1996 12:36:44 -0800 Xref: main.gmane.org gmane.emacs.gnus.general:4718 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4718 >>>>> "Greg" == Greg Stark writes: Greg> There's a lot of real gains to be made here. Gnus would be Greg> a lot more useful if it didn't lock up Emacs while doing Greg> long operations like listing groups, checking for bogus Greg> groups, or entering a group (once took me over 30 minutes). >>>>> "Steven" == Steven L Baur writes: Steven> It's making less and less sense to me to have Gnus wait Steven> while reading the NNTP active file at startup, with mail Steven> to be read and such. Not to mention a couple of nnkiboze processes that would be sooo nice to run in the background. I assume a multithreaded emacs is non-trivial? -kzm From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4719 Path: main.gmane.org!not-for-mail From: gsstark@MIT.EDU (Greg Stark) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 16 Jan 1996 06:05:31 -0500 Organization: Massachvsetts Institvte of Technology Sender: gsstark@fierce-bad-rabbit.MIT.EDU Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> <9601161034.AA07122@krone.ii.uib.no> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145426 30568 80.91.224.250 (20 Oct 2002 20:23:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:23:46 +0000 (UTC) Cc: Steven L Baur , ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id EAA20835 for ; Tue, 16 Jan 1996 04:01:20 -0800 Original-Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 16 Jan 1996 12:05:37 +0100 Original-Received: from FIERCE-BAD-RABBIT.MIT.EDU by MIT.EDU with SMTP id AA18096; Tue, 16 Jan 96 06:05:24 EST Original-Received: by fierce-bad-rabbit.MIT.EDU (5.57/4.7) id AA12845; Tue, 16 Jan 96 06:05:32 -0500 Original-To: ketil@ii.uib.no In-Reply-To: Ketil Z Malde's message of Tue, 16 Jan 1996 11:34:02 +0100 Original-Lines: 19 Xref: main.gmane.org gmane.emacs.gnus.general:4719 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4719 >>>>> "Steven" == Steven L Baur writes: Steven> It's making less and less sense to me to have Gnus wait Steven> while reading the NNTP active file at startup, with mail Steven> to be read and such. Not to mention a couple of nnkiboze processes that would be sooo nice to run in the background. I assume a multithreaded emacs is non-trivial? -kzm The point I'm trying to make is that you don't need a multithreaded emacs. The interface to network streams and subprocesses is already asynchronous, we just need to make the interface to Gnus backends asynchronous as well. Some existing interfaces already support this. I've seen asynchonous mh, discuss, and rmail interfaces. (well I haven't actually seen the last one, but i'm told it almost exists.) greg From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4720 Path: main.gmane.org!not-for-mail From: Massimo Campostrini Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: Tue, 16 Jan 96 14:05:23 +0100 Message-ID: <9601161305.AA08071@sunthpi3.sunthpi> References: <199512280453.XAA00789@perdiem.cygnus.com> <9601161034.AA07122@krone.ii.uib.no> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145427 30569 80.91.224.250 (20 Oct 2002 20:23:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:23:47 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id GAA21161 for ; Tue, 16 Jan 1996 06:28:00 -0800 Original-Received: from ipifidpt.difi.unipi.it (ipifidpt.difi.unipi.it [131.114.8.130]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 16 Jan 1996 14:11:21 +0100 Original-Received: from sunthpi1.difi.unipi.it by ipifidpt.difi.unipi.it (AIX 3.2/UCB 5.64/4.03) id AA88770; Tue, 16 Jan 1996 14:05:00 +0100 Original-Received: from sunthpi3.sunthpi by sunthpi1.difi.unipi.it (4.1/SMI-4.1) id AA06412; Tue, 16 Jan 96 14:00:01 +0100 Original-Received: by sunthpi3.sunthpi (4.1/SMI-4.1) id AA08071; Tue, 16 Jan 96 14:05:23 +0100 Original-To: gsstark@MIT.EDU (Greg Stark) In-Reply-To: gsstark@MIT.EDU's message of 16 Jan 1996 06:05:31 -0500 Xref: main.gmane.org gmane.emacs.gnus.general:4720 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4720 In article gsstark@MIT.EDU (Greg Stark) writes: > The point I'm trying to make is that you don't need a multithreaded emacs. > The interface to network streams and subprocesses is already asynchronous, > we just need to make the interface to Gnus backends asynchronous as well. > > Some existing interfaces already support this. > I've seen asynchonous mh, discuss, and rmail interfaces. > (well I haven't actually seen the last one, but i'm told it almost exists.) The standard `manual-entry' command interface has been asynchonous for a long time (at least since emacs 18). Cfr. `man.el'. Massimo Campostrini, Istituto Nazionale di Fisica Nucleare, Sezione di Pisa. WWW home page: http://www.difi.unipi.it/~campo/ From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4741 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 17 Jan 1996 03:51:15 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145446 30646 80.91.224.250 (20 Oct 2002 20:24:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:24:06 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id TAA31935 for ; Tue, 16 Jan 1996 19:18:28 -0800 Original-Received: from surt.ifi.uio.no (4867@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jan 1996 03:51:17 +0100 Original-Received: (from larsi@localhost) by surt.ifi.uio.no ; Wed, 17 Jan 1996 03:51:16 +0100 Original-To: ding@ifi.uio.no In-Reply-To: Steven L Baur's message of 15 Jan 1996 12:36:44 -0800 Original-Lines: 11 Xref: main.gmane.org gmane.emacs.gnus.general:4741 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4741 Steven L Baur writes: > Could the active file be read by a subprocess similar to the exmh-bg > mailchecker in exmh? No. But the thing that takes time is transferring the file from the server to Emacs, which is something that one doesn't have to wait for, really. I've got some ideas. We'll see whether they are doable. -- Home is where the cat is. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4740 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: Getting articles asynchronously..... Date: 17 Jan 1996 03:51:16 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: <199512280453.XAA00789@perdiem.cygnus.com> <9601161034.AA07122@krone.ii.uib.no> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145445 30644 80.91.224.250 (20 Oct 2002 20:24:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:24:05 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id TAA31899 for ; Tue, 16 Jan 1996 19:17:07 -0800 Original-Received: from surt.ifi.uio.no (4867@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 17 Jan 1996 03:51:18 +0100 Original-Received: (from larsi@localhost) by surt.ifi.uio.no ; Wed, 17 Jan 1996 03:51:17 +0100 Original-To: ding@ifi.uio.no In-Reply-To: Massimo Campostrini's message of Tue, 16 Jan 96 14:05:23 +0100 Original-Lines: 12 In-Reply-To: Massimo Campostrini's message of Tue, 16 Jan 96 14:05:23 +0100 Xref: main.gmane.org gmane.emacs.gnus.general:4740 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4740 Massimo Campostrini writes: > The standard `manual-entry' command interface has been asynchonous for > a long time (at least since emacs 18). Cfr. `man.el'. Yes, but man.el simply starts a man/sed/awk combo that runs in the background. There are no sequencing or data munging problems (and it's buffer-oriented to boot), so it's a completely different issue than making Gnus asynchronous. -- Home is where the cat is.