Re: asynchronous backends

[Ken Raeburn <raeburn@cygnus.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> >>>>> "GS" == Greg Stark <gsstark@MIT.EDU> 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