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

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: AppServer <haiku-appserver@xxxxxxxxxxxxx>
  • Date: Mon, 13 Jun 2005 17:41:23 +0300

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, 
and then unlock?

        So, I started explaining...
        When I proposed the actual design I had in mind a few aspects: service 
architecture, avoid locking for reduced context switch with kernel code, 
multiple CPU
performance by reducing dependences(semaphores) between threads, the use of a 
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 
For the server, it not a problem not having an immediate response, but for a 
this requirement IS A MUST! While the current design might work in theory, it 
fail in real life. I think, to have a responsive system, we need to use 
so that we can get the resource we really need _now_, the visible result being
        I may be wrong here, and in real life the design might work better than 
and _far_ better on multiple a multiple CPU machine.

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

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

        In R2/3, I'm quite sure we'll be using surfaces, each window will be 
buffered. This would allow us a simpler composition engine, AND the possibility 
each window do it's own clipping. More, it would allow us to do all drawing on 
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?


Other related posts: