>> 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?