I know about the select loop thingy, but this was just for static content. What I'm suggesting is to use threads to generate dynamic content (on multiple processors), then, if the output will fit into a socket buffer, send it by the thread. Then the thread can immediately go back to handle another request. If the output won't fit into a socket buffer, pass it to the select loop where the output can be drained at whatever rate the user will accept it.
Personally, I don't care if the select loop thread uses multiple processors. The content generation (the hard part) will use multiple cpus. It would be interesting to have a stat for how often threads are blocked while writing to the socket. J > On Saturday, September 29, 2001, at 03:59 AM, Jim Wilcoxson wrote: > > > if returning data to the user could go through a single-thread, > > multi-connection select loop if it would overflow the socket output > > buffer. Then an expensive TCL thread wouldn't be tied up waiting for > > a 300 baud modem to drain the server's response. (Another reason why > > more threads need to be configured and it's hard to tune.) > AOLserver 2.3.3 had this -- it was called select-loop serving. It was > taken out because it didn't use the other processors in a multiprocessor > machine; the threads do a better job of that. >
