[Boost-users] Fwd: boost::threads is it all about managed threads?

From: The Grumpiest Man You Know (mrgrumpyguts_at_[hidden])
Date: 2005-03-05 20:27:07

Dear Mr. Moderator,

I realize I have been a PITA over the last few days but on the off
chance it's that there's a mail snafu rather than a moderation
decision, can you confirm that you do, as your first aut response
said, give a positive acknowledgement for declined posts?  Or has that
policy changed because of the weight of traffic?

If I've crossed a line it might be quicker to let me know so I can go
find another place to post questions.

Thanks for your time, I appreciate the function you provide in the list.

Anthony Booker.

---------- Forwarded message ----------
From: The Grumpiest Man You Know <mrgrumpyguts_at_[hidden]>
Date: Thu, 3 Mar 2005 23:19:52 -0800
Subject: boost::threads is it all about managed threads?
To: boost-users_at_[hidden]

I realize I might be trying to read beyond my experience level but I
am having a blast and might even be getting somewhere learning a new
programming style, a little. :)  So, I've been looking at
boost::threads and pthreads while considering a problem.  I was never
a believer in threads, I come from an SMP background and always found
that for what I wanted to do, async IO beat the pants off threads.
Not that I want to start a war, just that I want to explain why I'm
happy with concurrent programming but a complete nonce case when
discussing thread programming.

I have an application in mind for comparison and it's not particularly
complex but it's a monster in LOC, mainly due to the liberal use of
FORTRAN in whatever language the compiler happens to take.  But one of
the things it does have, that I'd rather not re-implement, is a
request service library.  That library picks up an incoming request,
goes and carries out the action and then returns the result.  The
requests are of unbounded duration and there are multiple clients so
the service times are pretty sad.  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 vector<boost::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?

If you're still with me thanks very much for your time and help and
let me know if I'm dragging the list off topic and I'll go find
someone else to bug.

--
Blue Skies
-- 
Blue Skies