[boost] Boost.Threads: thread design

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-09-04 09:35:03

I know people have been asking what direction the thread design will take
after the discussion about exception handling and that I've not responded in
quite some time.  Sorry, but I'm swamped on my end with a lot of non-Boost
stuff.  I have managed to find some time to think about and play with
various design ideas, but I'm not ready to answer the specific questions
people have yet... there's too many little details I need to work out first.
Once I have a design I'm happy with I let everyone know and address all of
the questions.

In the mean time... I've found some issues with some of the ideas we've
talked about.  The biggest among them is with providing a type safe return
value when a thread is joined.  The proposal was to make the boost::thread
type templatized on return type, but this causes serious problems with use.
We no longer have a single thread type, but instead have an open ended set
of thread types.  Not a big deal from the point of view of the thread
creator, but this renders "self()" operations (the default constructor in
today's design) nearly impossible to use.  You have to know what type of
thread "self" is, which isn't possible in many valid use cases.  I can think
of a few ways around this, such as having a special thread type usable as a
"self thread" that has no return value and can wrap, or making the return
type a boost::any, but I'm not sure I care too much for any of them.  It
still seems cleaner to me to handle the return value semantics through the
function object instead of through the thread object.  (And yes, if we
decide to go that route I'll try and provide a lot of the plumbing that will
make such usage as easy as possible for users.)

I'd appreciate thoughts/comments on this issue.

Thanks,
Bill Kempf