2010/5/19 Guido Trotter <[email protected]>: > On Wed, May 19, 2010 at 5:08 PM, Michael Hanselmann <[email protected]> wrote: >> So you would submit two kinds of tasks (messages and job updates) to >> the client request queue? I wonder whether having just one thread >> dedicated (which could be a single long-running task in the client >> request pool) to sending updates instead of always submitting a new >> task. During the lifetime of a job there can be many, many updates. >> >> Either way you need something actively checking the subscriptions for >> timeouts (not on the connections, but for waiting, so that you return >> if there was no change for e.g. 30 sec). I think this would be easier >> with a long-running thread. > > This goes against reducing the number of thread sets, though. > I'd rather have the second type of request in the client queue.
It's already a lot better to have a single thread take care of all WaitForJobChange (and maybe other long-running requests) instead of blocking a thread for each (as done currently). > Anything which requires deferring an action (this or what you describe > above) can be implemented by scheduling the mainloop to do it. > This work as long as it's "fast" actions: things like "send the job > change update if no other update happened" (or send a message to the > client thread pool to do so) or "send an update saying nothing > happened after some time" (or again, send a message to the client > thread pool to do so) should qualify. Checking a job's changes requires a lock and, even more importantly, serialization/deserialization of potentially large data. I think this should not be intermixed with client I/O (for the same reason why serializing the request reply message should occur in the thread sending the reply). You still can have a second mainloop in a separate thread just for scheduling. Michael
