Re: [Boost-users] Re: Re: Re: thread::thread() in Windows

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-12-09 12:49:52

Yuval Ronen wrote:

[...]

> According to your proposition, if I understood correctly, there is no
> no-parameters constructor to thread, and all threads are joinable.
> This is exactly what I was preaching to in my suggestion, so there is
> no argument between us there. The difference is that you offer to add
> a new thread_id class which I think is of no use at all. You need to
> add some kind of connection between class thread and class thread_id,
>    something like: thread_id thread::get_thread_id(); // thread method
> and then you'll go around and compare thread_ids. What for?

For

    thread_id get_current_thread_id();

presumably.

> If we agree that threads cannot be copied,

We don't. More details below.

> it means that each thread can be
> represented by only one thread object. Pass the address of thread
> objects and compare them, if you really want to. It'll give you the
> exact same result.

The problem with your reasoning is that the thread object may have been 
destroyed. Its lifetime is not tied to the lifetime of the thread.

Threads are noncopyable for historical reasons. Bill Kempf's original design 
had copyable, reference counted threads. Beman Dawes argued that a thread is 
conceptually very similar to an fstream, so it should be noncopyable, and 
Bill found his arguments convincing enough. I argued for what seemed like an 
eternity that this is wrong, and the user should never see a thread 
"object", only a thread handle (tentatively called thread_ref at the time) - 
essentially a shared_ptr<thread_impl>. The proposed API was

    thread_ref create_thread( F f );
    thread_ref current_thread();
    void join( thread_ref tr );

I was unable to convince Bill Kempf to change the design (back), however.