Date: 2001-06-22 13:10:29
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:06 PM 6/22/2001, williamkempf_at_h... wrote:
> >> It may be unusual, but threads are unusually dynamic objects,
> >> the J/Thread approach matches my intuitions. But perhaps I have
> >> been infected by java.
> >Possibly. That's why I said it *may* be the proper compromise.
> >also imagining a thread type that was noncopyable, that spawned
> >actual thread of execution in the constructor, and that did a join
> >on destruction unless a detach() method had been called in
> >This would be more in fashion with C++ design, though it makes it
> >least slightly more complicated to share management
> >between various objects, which is a common task. It also makes
> >things difficult or impossible to do. For instance, a self()
> >no longer is viable or appropriate, and spawning several threads
> >loop becomes more complicated.
> and also in a different message:
> >I'm still wondering if we shouldn't have two concepts here. The
> >thread class would remain much as it is now, except that it would
> >be copyable and the create() method would return a thread_desc
> >instead of a thread. Again, this was the approach taken by
> >and seems to be a nice compromise between the two designs being
> >discussed so far.
> My intuition right from the start has been that there are two
> thread and thread_desc, and thus there should be (or at least might
> be) two classes. If you provide only a thread_desc, I'm sure lots
> people will write their own threads wrapper to hide and manage the
I'll code this up as two concepts in the next few days. Actually,
there will be very little modification from what already exists, so
the change is trivial, despite the major change in conceptual
> By the way, have you considered specifying that the initial
function of a
> multi-threaded program be main_thread()? That way you could supply
> canned main() would could create the initial thread, making it
> of a special case. For example self() returning a thread& could
> in main_thread() (although the complexity might be O(log n) on the
> of running threads, instead of O(1).) Or you could make a thread& a
> argument to each initial function, including main_thread(), so the
> self would be lessened or eliminated.
No, I never considered this. For MT systems every program is going
to have a main thread regardless of whether or not main() or a
main_thread() is used as the program entry point. For these systems
it's always possible to get the "main thread" through some sort of
self() style function any way, so all that's needed for Boost.Threads
is a method to "adopt" the thread from such a call. This ability is
likely to be needed for other threads any way, so I'm not sure I see
a lot of benefit to requiring a thread_main() entry.
> Anyhow, I think you are right to review the current design in light
> comments. Even if you still end up with a single descriptor class
> than two concepts and matching classes, it will be stronger for
> that that is what it is, and tailoring the interface accordingly.
I'm going to wait to hear any further thoughts on this, but I expect
I'll go to a two concept approach.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk