SciFi <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
