Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-22 08:56:34

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:21 PM 6/21/2001, Greg Colvin wrote:
> >From: <williamkempf_at_h...>
> >> ... Beman sugggests ...
> >> So in my mind, either change the class name to something that
> >> identifier, handle, or the like, or change the semantics to be
> >> thread-like and less thread_id like. Make it noncopyable, and
> >> forth. I don't entirely see how to do that. I guess a
> >> static or free function could return a pointer to a thread
> >> 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.
> >>
> >> 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.
> Now iostreams could have done a C-like fstream interface which was
> just a holder for a file id or handle. The fstreams would be small
> 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?

I'd prefer this. Unlike iostreams threads often need to be grouped
and managed by other objects, which is problematic when there's no
copying semantics.

> The object directly representing a thread, noncopyable

Another argument against this design is that such an object should
also destroy the thread, and thread cancellation is a tar baby
waiting to pull us all into that briar bush. Boost.Threads _may_
have to support cancellation at some point, but the dangers of this
are great enough that it should be an optional part of the library,
and destructors aren't very optional.
> 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"?

Another suggestion would be thread_desc or thread_descriptor.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at