httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Jim Gettys)
Subject Re: [PATCH] select-thread-hybrid-01.patch
Date Mon, 17 May 1999 17:44:10 GMT

> Sender:
> From: Dean Gaudet <>
> Date: Mon, 17 May 1999 09:30:37 -0700 (PDT)
> To:
> Subject: [PATCH] select-thread-hybrid-01.patch
> -----
> OK I've managed to serve a few requests with this, so it's time to post ;)
> Building:
> Get and build bind-8.x (I'm using bind-8.2).  You want the wonderful
> eventlib which the ISC folks have written for us, and released under a
> BSD-style license.  This is a convenient select/poll wrapper which
> provides timer and fd events.  Paul's comments say he had inputs from lots
> of folks -- including the X folks... so I'm guessing Jim Gettys' comments
> were taken into account... and so I'm just trusting the code rather than
> looking at it.

Dunno the geneology of this code (and haven't looked at it).  The X server 
internally has always been select driven, and has also taken advantage 
of select timeouts (for example, this is how it knows to do screensaver 
operations).  AF, an audio server I built with some other folks added 
a simple tasking package (each task, or thread, promised not to block
or run too long).

I know that John Ousterhaut built such a thing for TK as well, reputedly
quite clean (John writes good code!), and not X specific.

The basic loop of an X server is roughly as follows:

   call select (fd of clients + fd for accept, mask showing work to do, timout)
	If (new connection) accept it
	if (old connection went away) close it
	if (timeout) do what is pending (screensaver, or other things like
	foreach (fd of open connections with data available)
		read as much data as is available non-blocking
		foreach (request in data read) {
			If (full request present)
				call request routine
		flush output buffer of FD
go to loop:
This is not completely fair for a scheduler: in particular, a single
client can execute quite a few requests before something else gets run;
but it has been fair enough for X's use (you don't want to keep changing
graphics contexts between clients; this can be expensive on alot of hardware).

On mean, X executes of order 100 instructions/request overhead total, 
including TCP overhead of moving the data.  The bottom line is that X 
is most efficient when most loaded: as one client gets the server busy, 
other clients will have more chance to send more requests, and so the 
system call/request keeps dropping as the server is loaded, to WAY under 
1 system call/request on average (since the frame buffer is generally 
mapped to allow futzing with the device registers directly).  

My pentium 400 at home, for example, gets around 2,000,000 no-ops/second; 
I get something like 3,300,000 single pixel dots/second (poly request).  
The protocol, however, is very much more compact and simpler than HTTP...
I don't mean to make a direct comparison, but shall we just say that
HTTP looks nothing like what I believe a simple, clean wire protocol should
look like.  In X's case, however, we were lucky enough to stamp out the
first generation of the protocol, a luxury that will be difficult with
the Web.
					- Jim

Jim Gettys
Industry Standards and Consortia
Compaq Computer Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.,

View raw message