On Wed, 4 May 2005, Stefano Ceccherini wrote: >> Separating tasks for/in threads makes it easier for the code >to be >> maintained and >> enforces the concept of multi-threading, BeOS is very proud >of. >:-) Honestly, I can't follow the reasoning. When you serialize tasks by executing them in one thread instead of executing them in several threads, using locking where appropriate, how does that further multithreading? It definitely reduces parallelism. Which is particularly not helpful on SMP machines. A thread should have high priority when it needs to be responsive in any way, i.e. needs small latencies. Isn't the additional messaging, counterproductive to that cause? Anyway, I'll stop discussing at this point. I have no idea what the RootLayer thread is supposed to do. Implementing it like you did may be just the best decision, I was just wondering about the reasons. > Yes, but the problem in this case is that RootLayer ends up to be the > class doing everything, which has to know about every other class, and > that's much more a problem for maintainance. Well, something like that is easily beautified. Just encapsulate the code in a class that implements some `executable' interface (think Java Runnable) and pass an instance of that class to the target (RootLayer) which can then execute the task without knowing any of its dependencies directly. CU, Ingo