On 12/31/05, Gustaf Neumann <[EMAIL PROTECTED]> wrote: > Zoran Vasiljevic wrote: > > > > But that would occupy the conn thread for ages, right? > > I can imagine several slow-line large-file uploads could > > consume many of those. Wasn't that the reason everything > > was moved in the driver thread for the 4.0 ? > > > > What I have/had in mind is aync writes from the driver thread. > > Most of the OS'es have this feature (kaio) so we can employ it. > > The question of locking, however still remains in such case. > > So the decision has to be made on: what is cheaper? Locking > > or spooling to disk out of the conn thread? I have no real-life > > experience but I'm inclined to believe that spooling out of the > > conn thread would be more costly. > > > > What do you think? > i have not much looked into the c-code, so please forgive, if my > mail here is obviously wrong or naive. > > One thing, which i dislike about the aolserver for file uploads is that > there is no hook for early permission or quota checking; one has to > upload the whole file before aolserver is able to give some feedback. > i see this even more important than the progress bar.
I agree. This is important. > What about the following model: > > A) HTTP header (up to empty line) -> driver thread > > B) Then passing control+socket to a separate receiving thread that > 1) issues a callback at the start (e.g. for permission checking) > 2) does async i/o to receive the message body (e.g. PUT, POST request) > here, one can issue as well callbacks per async block, and decide > fom tcl, whether one would like to spool to memory or disc. > > C) When end of message received, pass control to connection thread as usual. > > The receiving thread is like a connection thread with tcl stuff; when the > receiving thread is implemented via libthtread, there won't be probably > much locking. Only one receiving thread will be necessary. > The overall model could be quite compatible with the aolserver, since the > connection tread is invoked when all data is received. It would be necessary > to pass context information from the receiving thread to the connection > thread > to avoid double permission checking. > > It could as well make sense, to pass control to the receiving thread only > for chunked content. Maybe, the receiving thread is not needed at all, > since the driver thread could handle everything as well. This is similar to the way the old Flash web server worked. It had a pool of IO threads which would make sure data on disk was in memory, possibly blocking, before the main thread would try to write it out to the client. Multiple threads are used to get more throughput out of the disk. As one thread blocks, another can submit a request. Your single thread helper mechanism above may not work the disk as hard as multiple threads, but it does mean that the driver thread doesn't have to block waiting for disk. You've also moved quota checking etc. into the helper thread. This doesn't so much matter if there's just one, but with more than one you have to remember that a Tcl interp will be allocated for each, and they'll be just as heavyweight as normal conn threads. We have a similarly problem with normal downloads, i.e. writing data to the client, an mp3 file for example, ties up a heavyweight conn thread. A generic pool of IO threads might be useful in a number of places. Of course, this is just a simulation of AIO to disk, but see my other email for why AIO is not so easy. AOLserver HEAD has a new filter type, NS_FILTER_PREQUEUE, which gets called just before the connection is queued for processing by a conn thread. The unique thing about this filter type is that the registered code runs in the context of the driver thread. Unfortunately that's after all the data has been read and spooled, but we could implement it such that they ran just after all headers have been received. If you want to check quotas by querying a database then then this doesn't help -- your db query will block the driver thread. These filters will have to be coded carefully. We could also implement non-blocking db calls, and that's certainly something I'm interested in, but it doesn't help right now. However, if the code you want to run is short and non blocking, prequeue filters we be a good way to run quota checks and such without having to involve a conn thread at all. Prequeue filters don't help with upload tracking, nor with actually spooling large uploads to disk.
