From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-21 20:56:02
From: Beman Dawes <bdawes_at_[hidden]>
> At 04:21 PM 6/21/2001, Greg Colvin wrote:
>
> >From: <williamkempf_at_[hidden]>
> >> ... Beman sugggests ...
> >> So in my mind, either change the class name to something that denotes
> >> identifier, handle, or the like, or change the semantics to be more
> >> thread-like and less thread_id like. Make it noncopyable, and so
> >> forth. I don't entirely see how to do that. I guess a create_thread
> >> static or free function could return a pointer to a thread object.
> >> Then delete of the pointer would kill the thread. But it would have to be
> >> a weak pointer because the thread might already be dead and thus the
> >> object already destroyed.
Right. So is_alive() returns false, and most other calls become
no-ops or throw an exception when the thread goes away.
> >> class thread : noncopyable
> >> {
> >> // All constructors private, so thread::create()
> >> // is the only way to create a thread
> >> thread();
> >> ...
> >> public:
> >> ~thread(); // assert(*this != self())
> >>
> >> bool is_alive() const;
> >> void join();
> >>
> >> static thread * create(void (*threadfunc)(void*), void*
> >> param);
> >> static thread & self();
> >> static void join_all();
> >> static void sleep(const xtime& xt);
> >> static void yield();
> >> };
> >
> >I understand noncopyable, but why force heap allocation via the
> >create call?
>
> Because I just picked up Bill's id semantics interface, and hacked it for a
> minute or two. As soon as I sent it I realized there was no obvious need
> for forcing heap allocation. A more usual constructor would be better, at
> least for discussion's sake.
>
> Back to the main discussion. It seems to me that a thread is similar to an
> fstream in that it represents a resource object which actually is owned by
> the operating system.
Yes. And like iostreams it provides a more portable and safer interface.
> Now iostreams could have done a C-like fstream interface which was really
> just a holder for a file id or handle. The fstreams would be small value
> types that were typically passed by value, could be freely copied with no
> effect what so ever on the underlying file, and so forth.
>
> Of iostreams could have (and did) try to make an fstream object look and
> act as much as possible as if it were in fact a file object itself, not an
> id, handle, pointer, or other link to the real thing.
>
> Now substitute "thread" in the above.
>
> Which would people prefer, and why?
>
> The id/handle/pointer/link copyable semantics?
Yes please.
> The object directly representing a thread, noncopyable semantics?
No thank you.
> If you like the id/handle/pointer/link semantics, would you still like to
> see the class called "thread" rather than "thread_id" or "thread_handle" or
> "thread_pointer" or "thread_link"?
I don't much care about the name yet, but "thread" is fine by me.
Maybe thread_proxy?
A slightly more complicated interface might be the non-copyable
thread and a copyable thread_ptr with an operator->() that returns
thread*, and a counting-weak-ptr semantics that keeps the thread
object around, alive or dead, until the last thread_ptr goes away.