[boost] Boost.Threads: thread design

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-09-04 10:04:09

William E. Kempf writes:
 > 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. 

What operations do you think are necessary for a thread object that refers to
the current thread? The only use I can see is checking whether or not it is
equal to another thread object; this could be achieved by having a special
type of thread object, such as current_thread, whose sole purpose is for use
in such comparisons. The existing docs specify that a default-constructed
thread object is only valid within the current thread, and you can't join it;
providing a special type for that purpose seems like a good idea to me.

Anthony