From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-22 12:37:39
At 12:06 PM 6/22/2001, williamkempf_at_[hidden] wrote:
>> It may be unusual, but threads are unusually dynamic objects, and
>> 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. I'm
>also imagining a thread type that was noncopyable, that spawned the
>actual thread of execution in the constructor, and that did a join()
>on destruction unless a detach() method had been called in between.
>This would be more in fashion with C++ design, though it makes it at
>least slightly more complicated to share management responsibilities
>between various objects, which is a common task. It also makes some
>things difficult or impossible to do. For instance, a self() method
>no longer is viable or appropriate, and spawning several threads in a
>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 not
>be copyable and the create() method would return a thread_desc
>instead of a thread. Again, this was the approach taken by J/Threads
>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 concepts,
thread and thread_desc, and thus there should be (or at least might well
be) two classes. If you provide only a thread_desc, I'm sure lots of
people will write their own threads wrapper to hide and manage the
By the way, have you considered specifying that the initial function of a
multi-threaded program be main_thread()? That way you could supply a
canned main() would could create the initial thread, making it far less
of a special case. For example self() returning a thread& could work even
in main_thread() (although the complexity might be O(log n) on the number
of running threads, instead of O(1).) Or you could make a thread& a calling
argument to each initial function, including main_thread(), so the need for
self would be lessened or eliminated.
Anyhow, I think you are right to review the current design in light of
comments. Even if you still end up with a single descriptor class rather
than two concepts and matching classes, it will be stronger for recognizing
that that is what it is, and tailoring the interface accordingly.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk