I guess I was unclear in my earlier note: 1. The HTTP driver thread reads all input for request, w/o blocking. My understanding is that this is now happening in AS 4 - great!
2. A conn service thread creates the output, either by running a TCL script, executing fastpath to read a file into memory, etc. This might do stats, file I/O, database I/O, etc., and may block. The result of this thread is a memory buffer. 3. The HTTP driver thread spools the memory buffer back to the client, w/o blocking. I wasn't suggesting that there should be no blocking in step 2, when the output is being created. That's why multiple connection service threads are needed. But the problem of a connection service thread being tied up while it spools a large page/image is eliminated. In the application of an image server, it would be nice if there could be one fastpath thread that did all non-blocking filesystem I/O (actually just reading is needed), or an asynchronous sendfile, but I agree with you that there are not good portable ways to do that yet. Jim > On Wed, 2004-08-18 at 09:21, Jim Wilcoxson wrote: > > ... > > > > AOLserver is ideally suited to the majority of server tasks. About the > > > > only shortcoming which comes to mind is that conn threads are required > > > > to do blocking writes. But fixing that would be of benefit to the HTTP > > > > processing side too. > > > > > > So, we want reader threads and separate writer threads now, too? > > > Exactly how many free-range threads do we want roaming the server > > > prairie, here? > > > > You don't need reader threads and writer threads. If input and output > > both use event-driven, non-blocking I/O, you can use one thread to do > > both, or one thread per CPU, like TUX. > > > You can't do non blocking I/O on a file descriptor backed by disk. Not > portably at least. Calls like stat(2) to get the last mod time may also > block. > > That's why I suggested a pool of writer threads. TUX actually does > something very similar to handle potentially blocking disk I/O. > > > One of the biggest resource hogs is not the conn threads themselves but > the Tcl interps they drag round with them. If you're interested in > cutting down on resource usage, you might want to take a look at this > RFE: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1012103&group_id=3152&atid=353152 > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
