[hunchentoot-devel] COMET with Hunchentoot?

[Hans Hübner]

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.

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.

Nothing of this is on my current task list, sadly.

-Hans