[haiku-appserver] Re: BScreen support

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.

Other related posts: