[Pan-users] Re: 0.129 - a few minor issues

[Duncan]

SciFi <address@hidden> posted
address@hidden, excerpted below, on  Fri, 11 May 2007
09:05:12 +0000:

> My bug-report also tries to show that a multi-CPU machine is not being
> utilised very well at all, but as mentioned in the report I am wondering
> if it's intrinsic to glib/gtk/whatever that is responsible here.  And as
> mentioned, I have gone through every component to be sure I've got
> [p]thread support enabled etc. if available during its configure.

Multi-CPU/multi-core would intuitively need multithread it's true, but 
intuition isn't always correct, and given intelligent use of threading at 
the bottlenecks and with the serious resource locking and thread timing 
related debugging issues, a fully multithreaded app isn't necessarily the 
best answer, particularly if it does little or nothing to address the 
bottlenecks.

Rather, I believe Charles' single-threaded core, multi-threading where it 
can demonstrably improve performance, is a solid approach.  The issue at 
this point is simply that the rewrite remains far newer and less mature 
than the years and years of testing and coding that had gone into the 
older version by 0.14.x, so naturally there are places that haven't been 
fully optimized (whether that means multithreading as it will in some 
cases, or simply recoding with specific issues in mind, as in the below 
for example).
 
> I see I'll need to file at least two more bug-reports as I need to
> document specific areas for each one; it's better to separate the issues
> this way.  For ex. the next report I should file is as follows:  As I
> type this with an external editor right now, no downloads can progress,
> everything under pan2's umbrella is frozen until I save this tempfile so
> it can continue.

That's a definite bug, not just a missing feature.  Downloads can and do 
progress while using the built-in editor, and they should when using an 
external editor as well.  I'm guessing that this was simply overlooked, 
however, and not caught in testing until now as relatively few use an 
external editor.  IOW, it's just the immaturity of the new code, not an 
intrinsic single-threading vs. multithreading issue.  Definitely file 
that as a bug on its own.  If the hatch external editor functionality is 
implemented with a callback, so pan can then continue about its other 
business, downloading and the like, instead of instituting it in-line, 
holding up the entire app, there's no reason a separate thread should be 
needed, and in fact hatching such a thread could be considered a waste of 
computing resources.

> Charles should've known his single-thread approach in the rewrite will
> soon become a major issue with most ppl.  I'm sorry to say this but
> foresight should've been part of the rewrite (valour).  ;)

It's not the single-threaded approach that's really the problem.  Sure, 
multithreaded the entire app would be one way to address the problem, but 
there are other, less resource wasteful ways of managing the problem as 
well.  It's simply a matter of time, finding, bugging, and instituting 
appropriate measures (which in fact do include multithreading individual 
tasks at times), as individual bottlenecks are discovered.  IOW, it's an 
issue of maturity.  New-pan is a lot simpler to work with, both because 
of its modularity and because its core /is/ single-threaded, so progress 
is much faster.  However, it remains a relatively new rewrite and there 
are areas that simply aren't as smooth as old-pan, simply because they 
haven't had time to be smoothed out yet.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman