[hunchentoot-devel] COMET with Hunchentoot?

[Slawek Zak]

On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner <hans.huebner at gmail.com> wrote:

> On Sat, Feb 28, 2009 at 14:01, Slawek Zak <slawek.zak at gmail.com> wrote:
> > On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner <hans.huebner at gmail.com>
> wrote:
> >> 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.
>
> Wouldn't you be able to write a task manager that first reads the
> request header, then decides whether the request is a COMET request
> and queue it or hand it over to another thread for processing?  You
> might still want to have multiple connection handling threads in order
> to have some concurrency in request header reading, but such a scheme
> should be possible with the current architecture.  Or am I missing
> something?


It is possible, but handle-incomming-connection is now in fact a thin
wrapper around process-connection which does all the work, thus having
process management depend on request contents requires one to patch or
rewrite process-connection to simply avoid reading request data which have
been read already.
/S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090302/2778c308/attachment.html>