On Mon, Mar 2, 2009 at 11:49 AM, Hans Hübner hans.huebner@gmail.com wrote:
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?
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