[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-devel] Re: Ya know Pan2 is really single threaded, right?
From: |
Calin A. Culianu |
Subject: |
Re: [Pan-devel] Re: Ya know Pan2 is really single threaded, right? |
Date: |
Sat, 17 Mar 2007 20:44:27 -0400 (EDT) |
On Sat, 17 Mar 2007, Duncan wrote:
Is this intentional?
It's known and intentional, yes. Older pan (pre 0.9x, coded in C instead
of C++) was indeed multithreaded in its downloading.
Ah, ok. I figured. The code is otherwise pretty tight and such an
'oversight' was likely intentional. Thanks for answering that question!
Meanwhile, I've found it /much/ more my style and much less likely to
stall ongoing downloads if in the binary groups I download everything to
cache, then do local processing as a second round, after everything's
already downloaded. Of course, pan's default 10 MB cache isn't large
enough for this, but that's easily solved by tweaking the setting in
preferences.xml. (As with several "advanced" settings, there's no way to
tweak it in the GUI prefs, only by editing the config files directly.)
Hmm. Ah yes that didn't occur to me but I can see how it works and why
it works.
Still, you have to admit it is a bit labor intensive from the user
(downloading lots of binaries is a 2-step process in the UI) and is also
wasteful of diskspace. For example: if you are processing a huge NZB
queue (downloading a DVD iso can be like 4GB!!). If it's posted as 100
50MB .rars, you waste all 100*50MB in the cache rather than just 1*50MB
for each attachment.
As I said, however, I've never seen Charles explain his choice, but
expect I'd learn something about threading as well as about pan seeing
it, so thanks for asking and hope he replies too. =8^)
I have been reading the code and trying to add a worker thread pool model
to the code.
I can see now that it introduces a lot of complexity and potential bugs to
the code -- already the code assumes that everything runs in 1 thread.
But I will do my best to aviod race conditions by locking shared data as
best I can, and to only introduce threading where it will actually benefit
the user (better network utilization, not stalling on uudecode, etc).
I have experience with multithreaded coded so hopefully I can do this
somewhat elegantly and in a bug-free manner.
Likely he didn't make the code multithreaded because his initial pass was
to just get Pan2 working, and perhaps he intended to go in later and added
multithreading?
Anyway I am taking a stab at this now -- have been spending a few hours
on it already. I'll let you guys know if I give up, lose interest, have
or actually have an implementation that works.
Then you guys can decide to keep it or not.
Thanks for the info and yes, I also would like to hear Charles' thoughts
on this.
-Calin