From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-21 20:29:58
At 04:21 PM 6/21/2001, Greg Colvin wrote:
>> ... 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
>> a weak pointer because the thread might already be dead and thus the
>> object already destroyed.
>> class thread : noncopyable
>> // All constructors private, so thread::create()
>> // is the only way to create a thread
>> ~thread(); // assert(*this != self())
>> bool is_alive() const;
>> void join();
>> static thread * create(void (*threadfunc)(void*), void*
>> 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
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.
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?
The object directly representing a thread, noncopyable semantics?
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"?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk