Re: [Pan-devel] Ya know Pan2 is really single threaded, right?

[Calin A. Culianu]

On Fri, 23 Mar 2007, Charles Kerr wrote:

> Calin A. Culianu wrote:
>
> >  Why does pan2 ever create a threadpool?  It's actually single-threaded!
>
> Hi Calin,
>
> I've talked about your nice patch in bugzilla, so here I'll just answer
> in general about the rationale behind Pan's use of threads.

Yes, I am simply replying to this for completeness of the archives.

> At one point Pan was fully threaded.  This made things more responsive
> than 0.14.x would've been otherwise, but at the cost of some stability
> and a _lot_ of code complexity.

After reading the code -- I completely agree.  And I remember once upon a 
time trying to modify pan many moons ago and finding it extremely 
fragile/complex.  Right now pan is REALLY fast (the network speed is 
great) and yes, it is much much much easier to think about what is 
happening and to maintain.

> To reduce that complexity in the rewrite, Pan's eliminated threads
> wherever possible and used them only to prevent freezing during
> self-contained work (socket creation/connection).  The only other
> candidate for threads I can think of is UUDecode.

Good design choice!


> This used to be bugzilla ticket #353317, slated for Pan 1.1, but
> since your patch is coming along so well we should use it sooner. =)

Cool!  :)

> I strongly agree that UUDecode belongs in a worker thread, but
> wouldn't go beyond that -- the next bottleneck is networking,
> and threads don't help there.  The single-threaded version of
> Pan downloads just as fast as the multithreaded one, and is
> significantly smaller.

Yes, very true.

> Even our threadpool poster child, UUDecode, has problems:

Heh, "poster child" eh?

> UUDecode is single-threaded, so the best we can do is a worker
> thread and a FIFO queue.  Anything else will devolve into that
> and is overkill.

Yep, precisely how it works in my patch.

Thanks so much for the comments, advice, and thoughtful discussion.

Cheers,

-Calin