On Sat, Feb 28, 2009 at 14:01, Slawek Zak slawek.zak@gmail.com wrote:
On Fri, Feb 27, 2009 at 5:14 PM, Hans Hübner hans.huebner@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?
-Hans