On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner hans.huebner@gmail.com wrote:
On Fri, Feb 27, 2009 at 16:42, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner hans.huebner@gmail.com
wrote:
On Thu, Feb 26, 2009 at 22:01, Jim Prewett download@hpc.unm.edu
wrote:
I'm not quite sure what I'm after except that the buzzword seems to be "COMET".
...
The cleanest way to implement a high performance I/O multiplexing framework that could be used by Hunchentoot would be by implementing multiplexed socket streams using coroutines. Obviously, that would require a coroutine library, and I am not aware of such a thing.
Don't you think that having separate thread handling comet would be
simpler?
I/O multiplexing to the clients with some sort of message queueing API
for
requests from the app engine would be sufficient to make it work? The
only
obstacle for multiplexed I/O is lack of portable non-blocking I/O
library.
Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that.
I see a bit of a problem with that API for this purpose. One would want to somehow distinguish between comet and non-commet calls. To do this you would have to inspect URI or method of the request to spawn a thread or pass the request to dedicated comet handler for example. Handle-incomming-connection is used to customize task creation. It uses process-connection to do the work which in turn calls get-request-data to get URI, method and headers. It's after taskmaster dispatch. It would be nice to be able to handle static content by single thread and dynamic content with one request per thread. Or even proxy the static content via external server. I don't know of any HTTP server able to do this :) Simplest method of implementing it would exposing process-connection API and adding optional argument, say request-info, which would be preloaded with info returned by get-request-data retrieved earlier to decide how to handle the request. Now you would have to rewrite process-connection altogether to get the same effect.
usocket has recently seen quite some changes to support non-blocking
communications, although I think that this work is not yet finished. Working on that would propably be easier than replacing Hunchentoot's networking layer.
Agreed. You must have some insider info on this ;) The only trace of non-blocking socket I/O in usocket that I could find was in two .txt files distributed with usocket 0.4.1
Regards, /S