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