On Thu, May 20, 2010 at 1:29 PM, Michael Hanselmann <[email protected]> wrote:
>> 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). > Sure. But if we can block no thread, we might as well. Anyway I'll keep this idea in mind, if it turns out to be easier to implement. > 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. > Yes. The plan is, if possible, to have it not require the lock, and to do it in a non-dedicated client thread, rather than in a dedicated waitforjobchanges thread. If the non-dedicated thread doesn't block on a request, then it's ok. Of course there's still time to go the other way. Can we defer this to later? Is it important to reach a final decision in the design? Thanks, Guido
