[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,
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:
