John Beardmore wrote: > Craig Ringer wrote: > >> Scribus is single threaded, > > In the long term though, is this because the algorithms can't be > parallelised, or because that's the way things have evolved ?
A bit of both, and a large dose of "it's way easier to get it right if you do it in a single thread". There are definitely areas where using multiple threads would be useful. Many of them are *not* so much to permit the use of multiple cores for computation as to permit better UI responsiveness. However, using multiple threads in situations where the threads must coordinate in non-trivial ways gets incredibly complicated in a hurry, and may not be worth it. There are lots of tricks Scribus and other programs can use (some of which Scribus does use) to hide the fact that the program can only do one thing at once. For example, it can delay work and do it in small chunks, in between processing user input. This can be surprisingly complex, though, and may sometimes perform significantly worse than doing it all in one go. Scribus can also periodically explicitly check for user input during long-running batch operations - but if you want to act on user input, not just do things like UI redraws and progress bar updates, then this too gets very complicated in a hurry. You may notice that the common element here is "get[s] very complicated in a hurry". Any sort of non-trivial parallel operation is *hard* to get right, especially with the rather primitive tools available in C++ and most other languages. Qt4 helps a little bit, but its facilities were not around when Scribus was initially written and they are very far from a complete solution to the complexity anyway. If Scribus was able to use multiple threads, it could reserve one thread for the interactive user interface widgets. Theoretically things like complex text reflow, canvas redraws, image processing, etc could be done in other threads. In practice, though, synchronizing everything correctly can be so complex that you have to think carefully about whether it's worth doing. The easy synchronization methods leave you with multiple threads, but with only one thread actually doing useful work at any one time, so you're not gaining anything. If you don't use such strictly limited synchronization you open yourself to the risk of weird errors and deadlocks caused by an overlooked interaction between threads. If you let the user keep on doing things while the program is busy working on a big task, you similarly create complexity. If a user can continue working on one document while another is being prepped for printing, for example, you have to make sure they can do nothing that modifies the state of the document being prepped for printing. I'm sure there are a few areas where Scribus _could_ benefit from muli-threaded parallelism, though. PDF export comes to mind. PDF has a nice structure where many PDF objects are largely independent, with only relatively few contact points between different structures. Scribus could almost certainly export multiple pages at the same time using different threads. It'd have to have a synchronized resource manager for xref updates and actual disk write-out, and would need to do some work to handle shared images, fonts, and other resources, but it should be possible. It could also use separate threads for the processing big fonts and images without holding up the rest of the page export. This would, however, require a total rewrite of PDF export, and possibly significant amounts of work elsewhere in the code. It'd be a huge job, and wouldn't be a huge win if all it did was parallel export. As it happens PDF export can be improved in other ways (processing images in small chunks without loading the whole thing into RAM, for example) but those improvements can be made without rewriting the whole thing. Mostly, though, there's not much Scribus could gain from multi-threading without a ground up rewrite. Even then, it'd be hugely complex to gain much except in a few big batch operations. [BTW: I mention PDF export partly because I've been idly wondering about adding support for multithreaded PDF writing in PoDoFo if a C++0x compiler is available, so I've been thinking about how thread-friendly PDF is.] > Mind you - I can imagine that in a cross platform development > environment, keeping things single threaded is one thing less to have go > wrong. The cross-platform aspect doesn't seem to be too bad so long as you stick to doing all your user interface in a single thread, stick to one thread for disk I/O to/from a particular file, etc. -- Craig Ringer
