[hunchentoot-devel] COMET with Hunchentoot?

[Slawek Zak]

On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner <hans.huebner at gmail.com> wrote:

> On Fri, Feb 27, 2009 at 16:42, Slawek Zak <slawek.zak at gmail.com> wrote:
> > On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner <hans.huebner at gmail.com>
> wrote:
> >>
> >> On Thu, Feb 26, 2009 at 22:01, Jim Prewett <download at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090228/4fc49efb/attachment.html>