pan-devel
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]