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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk