On Wed, May 19, 2010 at 5:08 PM, Michael Hanselmann <[email protected]> wrote: > 2010/5/19 Guido Trotter <[email protected]>: >> - The REQ_WAIT_FOR_JOB_CHANGE luxi request is changed to be >> subscription-based, so that the executing thread doesn't have to be >> - hogged while changes arrive. >> + waiting for the changes to arrive. Threads producing messages (job >> + queue executors) will signal the client work queue threads when there >> + is a change, and those will notify the subscribed clients. This should >> + be implemented without requiring the work queue threads to reacquire >> + the job queue lock, to decrease its contention. > > 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. > While currently not implemented, I'd like to see WaitForJobChange be > able to wait a short time (e.g. 1 second) after an update to wait for > further updates, so that there's less back-and-forth between server > and clients. This is very important for RAPI, where requests aren't as > cheap as for LUXI[1]. How would you implement something like this in > the new model? I'm currently thinking of a good way of doing it with > the current model. > 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. Thanks, Guido
