[Pan-users] Inefficiencies in Pan threading?

[Calin A. Culianu]

Pan seems like a really sweet binary newsgrabber and newsreader.  However
I noticed that it isn't too agressive in its thread usage when downloading
binary attachements.  Namely, I have a queue of tens of megabytes worth of
attachements in my task list, but Pan is only using 1 thread at a time to
download these binaries (I specified a connection limit of 4 in the server
config UI).  This doesn't sound so bad, however pan is spending a lot of
time idle while downloading (presumably as it is decoding the yEnc
attachements).  It would be nice if Pan grabbed as many files as there
are available connections from the task list and downloaded them all
concurrently.  That way, when one file is being decoded, another thread
could be busy transferring.  The more threads that are downloading at a
time, the less the chance that Pan will ever be sitting idle.

Ideally actually, decoding and downloading should be completely
deserialized so that a download thread passes the decoding job onto some
other background thread and then the download thread moves on to the next
attachement/file... that would avoid the observed stalls I sporadically
get with Pan.  (Other newsgrabber programs didn't give me these
stalls.. so I am assuming it is Pan and not my ISP or news server that
is stalling...)

I _did_ notice that sometimes Pan does use more than one download thread
at a time, but not usually.  I can't understand why it is behaving
inconsitently with respect to the number of concurrent downloads...

What do you guys think?

I am running Pan 0.14.0 built from scratch on a gentoo linux 1.4 system..

Other than that, I think Pan is great!

Thanks for a great program!

-Calin