On Thu, 3 Mar 2005 23:19:52 -0800, The Grumpiest Man You Know
I think that sounds like a job for threads; no need to alter the service code, just replace the routine that returns the results and bob's your mum's brother and I can get 10 at a time all sleeping waiting for the requested IO. But to not scare the natives I'd prefer to have a single thread unless the load actually demands more.
Now, my old C brain can see that the main thread can get it's thread ID from thread_self() and then just be one of the guys but I can't see how the boost::thread() can do anything but give me threads to manage. After stepping on myself with a vectorboost::thread :) I think this is the tao of boost::thread:
const boost::function0<void> run = &go; boost::thread_group grp;
for(int i = 0; i < 100; i++) { grp.create_thread(go); }
grp.join_all();
Is that right? What am I missing? How do I get a bunch of peer boost::threads?
This looks fine to me. I'd just suggest as a general design not stopping and starting threads with any great frequency (which is what you seem to suggest at the end of the first quoted para). Leave your threads running all the time, but use some sort of synchronized queue to pass them work to process (and perhaps a second queue to get results back). If all threads are busy the requests will start to back up in the queue, but when the queue is empty, all of the threads will block waiting for data, and this will use very little in the way of system resources. -- Caleb Epstein caleb dot epstein at gmail dot com