Mr. CTO,
I write this memo to announce my resignation in protest of the upcoming plans to revamp our mature and successful X-Server package as a multi-threaded system. I find that such a project, while perhaps attractive to those who know little of the details of the X-Windows system, is unlikely to yield better overall performance. More specifically - this proposal promises to add significant complexity without any real hope of making the system substantially more efficient than it already is.
The prime reason why threads would not add much efficiency to the system is that there are few system resources which must be shared between a potentially large number of processes. These processes will spend most of their time locked in competition for these very resources.
As you are CTO, I don't need to tell you that threads are most useful in the presence of slow system components - for example, while one thread waits passively for input to return from a slow-access disk, another thread can continue to execute. However, in the X-server system, no clients have access to a disk or any other such components on the server side. In fact, the only system components - or resource for which threads might compete - are the display and network access. All other resources a client program might use must be used on the client side.
First, let us consider mouse and keyboard input - might we allow client threads to manage their own input devices? The fact is, that no matter what, keyboard and mouse input must be handled by some central authority. This authority must decide which client to send input events to based on where on the screen the cursor was when the input was received, which windows are active and where they are, etc. Since no clients should have any kind of knowledge of or interaction with any other clients (unless this interaction be restricted to the server side), this is a task that the client threads cannot do. Therefore the keyboard and mouse routines are not good candidates for concurrency.
Before we go on to the display, note that clients can make non-display-related requests, such as manipulation of an off-screen image. Might we find some room for concurrency here? Unfortunately, no, since these types of request make no use of any hardware resources besides straight CPU time. It is therefore impossible to, for example, manipulate an off-screen image while at the same time drawing something to the display.
The only real system resources, then, are the display itself and network access. All the screen requests come to the server over the network in some sequential order. It therefore makes little sense to have a large number of client threads all waiting on the same network connection for any request that pertains to their small portion of the screen. Instead, it makes much more sense for a single central thread to process these screen requests as they come in. This is the solution we have currently implemented in our single-threaded X-server.
In essence, all potential threads would be competing for the very same resources all the time. Consider also that the single-thread server efficiently solves all of our potential synchronization problems already. In fact, the round-robin client treatment of the X-server - a direct parallel to a round-robin thread manager - is an approximation to multi-threading, except without all the additional code, complexity and processor overhead of actually managing the threads. The single execution thread simply marches through all the clients, giving equal time to each one, skipping ahead when the client is waiting on user input and fulfilling requests when clients wish to display something. This system is equivalent to a system in which a number of threads spend most of their time locked in wait for a very small number of system resources.
A multi-threaded server project, therefore, would involve considerable code overhead for thread implementation and synchronization, with very little or no substantial performance increase.
Sincerely,
Damian Isla