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.