[haiku-appserver] we need to think, I think...

Hi all,


        I had a talk with Stefano on Friday (IIRC) on why he shouldn't lock 
RootLayer object.
        I told him that, he should avoid locking as much as possible. But, if 
he doesn't have
a choice he should lock *only IF* he's reading data. For writing data(usually 
for region
calculation or writing data sensitive to clipping operations) he should 
ensemble a message
and add a case in RootLayer:: WorkingThread.

        Then he asked: Why do that? What are the advantages over locking, 
do_what's_needed,
and then unlock?

        So, I started explaining...
        When I proposed the actual design I had in mind a few aspects: service 
oriented
architecture, avoid locking for reduced context switch with kernel code, 
multiple CPU
performance by reducing dependences(semaphores) between threads, the use of a 
single,
higher priority thread for fast execution of clipping code(thread starvation), 
a clean
execution path, deadlock avoidance at development stage - RootLayer can lock 
any thread,
other threads *rarely/only_when_really_needed* lock RootLayer.

        IMO, the current design is good and clear (yes, I should've written a 
paper), BUT
after I talked with Stefano, I started having doubts.

        Why? Well, I think the current design is more suited for server than 
desktop.
For the server, it not a problem not having an immediate response, but for a 
desktop
this requirement IS A MUST! While the current design might work in theory, it 
may
fail in real life. I think, to have a responsive system, we need to use 
semaphores
so that we can get the resource we really need _now_, the visible result being
immediate.
        I may be wrong here, and in real life the design might work better than 
expected,
and _far_ better on multiple a multiple CPU machine.

        This asynchronous approach is OK, but I don't know if it's suited for 
desktop
computing.


        Now, a little talk about the future. :-)

        In R2/3, I'm quite sure we'll be using surfaces, each window will be 
double
buffered. This would allow us a simpler composition engine, AND the possibility 
that
each window do it's own clipping. More, it would allow us to do all drawing on 
client
side! Doing clipping and drawing on client side will give a significant boost 
to our GUI,
and with a multiple CPU machine I would expect a 35-45% speed increase.
        I am trying to adopt this concept into our present server architecture 
so that
the transition be easier. This is the main reason why I pulled the app_server
architecture on this way.


        Now, I'm very curios in your opinions. What do you have to say?


Thanks,
Adi.

Other related posts: