Ingo Weinhold wrote: > On Wed, 4 May 2005, Stefano Ceccherini wrote: > > >>> All commands that affect the visible regions must be >executed from >>> RootLayer's >>>thread context. When rebuilding regions, again, that must be >done from >>>RootLayer's thread >>>context. The solution: redirect this message to RT thread >and add a handler >>>for it. >>> Locking RootLayer is not a solution, that must be >kept to a minimum (2 >>> such >>>situations ATM). >> >>Well, if performance is what matters to you, I don't think that locking >>RootLayer in a display_mode change can affect performance in any way. If >>there is another reason, please elaborate more on this :) > > > I also don't quite understand why there should be a performance-wise > difference between serialization by locking and serialization by > processing by a single thread in principle. The only thing I see is the > additional overhead imposed by the messaging mechanism in the latter case. > > Generally using a benaphore locking is quite cheap, if the relative time > the lock is being held is small, since then the locking operations are > often merely atomic_add()s. What about when programming for multiple CPUs? I think messaging is justified in this case. Beside that, RL's thread will have a high priority(35-60 I think), while ServerWindow objects will have a merely 15. Also, locking from various threads is not nice at all from code flow PoV. 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. :-) bye, Adi.