asynchronous backends

asynchronous backends

[Greg Stark]

Ok, so sometime late in the september Gnus cycle i sent a nice long post
describing how an asynchronous interface could be done. Looking at the code
and the documentation now, it seems only half of what i described was done.

Namely, it's nice and all that nntp can pre-fetch articles before i ask for
them, but that's not the really cool idea. The really cool idea is that when i
enter a new group and there are four gazillion new articles and i really want
to read them all, while Gnus is fetching the NNTP scan it can let me go back
to editing my files (edit files? in emacs?) In general it really sucks a lot
when my emacs freezes up and i can't do anything without aborting the long
Gnus operation, some of us feel, uhm, like less of a person when our emacs is
locked up.

This would also let Gnus do some other cool things, like request group lists
from multiple servers at the same time. This makes more sense if more than one
backend is involed; if i have a slow network, why not go poking around in my
files while you're waiting for the nntp server to answer? Or let me start
reading my mail while it's still fetching the group list from some other
server. 

The reason i posted the original message was because i was implementing a
backend for which the existing emacs interface was asynchronous in precisely
this way. I still feel ashamed that i can't reproduce the single nicest
feature of the existing interface in my Gnus backend.

If you don't believe me that this is possible, think of the Man package. There
are some tricky bits, and if you try a second operation using the same virtual
server it may have to lock up anyways, but it could be done. I'll go find my
original post if needed, it explained this in more detail.

greg

Re: asynchronous backends

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "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?
Because the lisp interpreter is not threaded.  It can only do one thing at
a time.

If you really want to have Gnus running in the background you should start
a second instance of Emacs and run Gnus there.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBM1KZJZ6VRH7BJMxHAQFOPwQAmnxf7eF+V7TmDLESOfU54uibXs8c/r+O
FvezevWBWg2Pv3/nXKmEC5X3SAeQeztbyDYiLjv7VdNzCBLiwnfls6lRHOX1LFmF
YcaxFG6F4UnEAygR7XKsUY0i0EeEugmmQfTmpnPJ+5mAar7J3JqWMVe6uOvMcxpk
6Cpjsh8CCso=
=UP+1
-----END PGP SIGNATURE-----
-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
PGP Key: at a key server near you! \ accelerate to dangerous speeds.
                                    \ 

Re: asynchronous backends

[Ken Raeburn]

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

Re: asynchronous backends

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:

KR> This "just" means the multitasking has to be done at the application
KR> (gnus elisp) level.

Problem: there is no multitasking involved inside the Emacs kernel.  There
is a single process thread and a queue of functions to be evaled.
Everything that happens in Emacs is pushed into this queue and is evaled in
sequential order.  This includes the process filters associated with
asynchronous processes.  What makes process filters appear to be
multitasking is that they are automatically pushed into the queue by their
associated I/O streams.  When they are invoked while Emacs is "idle" their
evaluation is practically transparent.

That is, unless so much data is coming in through the I/O streams that the
process filters are being pushed into the queue every cycle.  If you want
an example of this, turn on asynchronous prefetch in Gnus, set the prefetch
number to something huge like 100, open a large newsgroup (at least as many
articles as you have your prefetch set), and select the first article.  Now
'n' to select the next and time how long it takes for that to happen
(assuming Gnus does not barf on the data overload :).

If you really want to multitask Gnus or Emacs in general you need to invoke
a new instance of Emacs and let the operating system handle it.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBM1RFqp6VRH7BJMxHAQFzFgP/bZ2BGZ4jo3cGvmanb95S9ZiV2aaRdq7k
ZkVsIfrH+r1e2lVCFFhHqplrwxhFnHW3oKstPmR2A624m5xRJMkUvs/3CZR+l9OT
YKrSbtlPdhEcmb4LQWVPI1vsvHEXpbXzGpLxfMPbC98rPT9K0pKnTLBfes5zrA4Z
khJ605uupvE=
=baJx
-----END PGP SIGNATURE-----
-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
PGP Key: at a key server near you! \ returned to its special container and
                                    \ kept under refrigeration.

Re: asynchronous backends

[Lars Magne Ingebrigtsen]

Greg Stark <gsstark@mit.edu> writes:

> This would also let Gnus do some other cool things, like request
> group lists from multiple servers at the same time. This makes more
> sense if more than one backend is involed; if i have a slow network,
> why not go poking around in my files while you're waiting for the
> nntp server to answer? Or let me start reading my mail while it's
> still fetching the group list from some other server.

Making Gnus asynchronous in many interesting ways is certainly
possible, but it's just hard.  Even doing trivial stuff (like the new
archie mode I slapped together yesterday (uhm, I think I may be
itching to start writing new code :-)
(<URL:http://www.ifi.uio.no/~larsi/other/archie.el>), and it's going
to be included with Emacs 19.35, it seems (and I have to do some test
runs under XEmacs as well))) takes quite a bit of typing, fiddling,
and means spending *much* more time programming than if one does
things synchronously.

And doing similar things with a behemoth like Gnus is a logistical
nightmare.

The results can be pretty neat, though.  Archie is fully asynchronous;
one just types `M-x archie RET search-string RET' and control returns
immediately.  Using `after-change-functions', Archie logs in on the
server, sends parameters, does the search and parses/generates the
result buffer asynchronously.  (Emacs locks up during the final phase,
though, just like Man does.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: asynchronous backends

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "GS" == Greg Stark <gsstark@mit.edu> writes:

GS> it is entirely possible to implement what i described without a
GS> threaded elisp interpreter, i explained how in my post last September.

Six months... have you written any of the code you describe?

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBM1aJl56VRH7BJMxHAQGtUAQAqQ2eX9x/2kUGFBi8zmGCYMfLXO7AOXNG
SKwO+Bi//lz3emiBQTwt4+C6OVkmZ78fo2PeILEqLcsgzvcZhdgUQcqjadnM/TDP
azPi39hEy74t1g3eiEvwpKeR7j0nKkMi8OvEyxWEQ/nhYUlkZRjHJxnzH1IRQOH5
7g548fTbP88=
=vyda
-----END PGP SIGNATURE-----
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
PGP Key: at a key server near you! \ 
                                    \ 

Re: asynchronous backends

[Greg Stark]

> Emacs cannot do this, not the way you want.

Wrong. Please go back and read my orginal post, This is precisely the claim i
refuted then. In fact i alluded to this in the last paragraph of my post,
neither the Man package, nor the W3 package, nor the original emacs interface
to the system my backend is for are figments of my imagination. 

I am familiar with both the Emacs features nntp uses (it doesn't actually use
process filters any more, read the code) and with threaded environments.
Threaded environments do not change what is possible, they only make
implementing asynchronous interfaces easier and more natural, it is entirely
possible to implement what i described without a threaded elisp interpreter, i
explained how in my post last September.

greg