From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/10714 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: asynchronous backends Date: 15 Apr 1997 21:23:17 -0400 Sender: raeburn@cygnus.com Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035150536 25897 80.91.224.250 (20 Oct 2002 21:48:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:48:56 +0000 (UTC) Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.5/8.8.5) with SMTP id SAA13331 for ; Tue, 15 Apr 1997 18:32:32 -0700 Original-Received: from cygnus.com (cygnus.com [205.180.230.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 16 Apr 1997 03:23:24 +0200 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.8.5/8.8.5) with SMTP id SAA12215; Tue, 15 Apr 1997 18:23:21 -0700 (PDT) Original-Received: from cujo.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA25754; Tue, 15 Apr 97 21:23:20 EDT Original-Received: by cujo.cygnus.com; (5.65v3.2/1.1.8.2/20Sep95-0235PM) id AA08406; Tue, 15 Apr 1997 21:23:19 -0400 Original-To: "(ding)" In-Reply-To: Stainless Steel Rat's message of 14 Apr 1997 16:52:57 -0400 Original-Lines: 44 X-Mailer: Red Gnus v0.76/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:10714 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:10714 Stainless Steel Rat writes: > >>>>> "GS" == Greg Stark writes: > GS> Namely, it's nice and all that nntp can pre-fetch articles before i ask > GS> for them, but that's not the really cool idea. The really cool idea is > GS> that when i enter a new group and there are four gazillion new articles > GS> and i really want to read them all, while Gnus is fetching the NNTP > GS> scan it can let me go back to editing my files (edit files? in emacs?) > > Emacs cannot do this, not the way you want. Gnus' asynchronous prefetch is > not really completely asynchronous. It uses a feature called process > filters. When data from a process arrives it causes Emacs to invoke the > process filter function associated with that process' output stream. But > Emacs can only do this if it is not already doing something else. Why? In the case Greg is talking about, the backend doesn't require a lot of processing time; it's waiting for a slow subprocess. The subprocess isn't cpu-intensive, either; it's waiting for lots of round-trips to lots of network servers. So doing random editing while waiting works just fine. At least, it does in the other, asynchronous emacs front-end to the same package. (There was some problem with emacs getting confused about which buffer an input event should get delivered to, but I think that's been fixed.) This isn't the only case where emacs may have to just sit and wait. Consider too what happens if your news server is on the far side of a slow link. I get this if I'm connecting by modem from home, or if I'm travelling and dialing up or using a local net provider. An nntp server can be slow sending headers or the active file. A pop server can be slow sending mail. An asynch interface would be great, but I'd settle for more parallelism in the gnus-related tasks. > Because the lisp interpreter is not threaded. It can only do one thing at > a time. This "just" means the multitasking has to be done at the application (gnus elisp) level. (I will not suggest multithreading elisp again. I will not suggest multithreading elisp again. I will not ....) Ken