Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-26 16:52:47

--- In boost_at_y..., Jeremy Siek <jsiek_at_r...> wrote:
> Here's an alternative interface, mostly due to Rich Lee.
The "thread" type
> here is similar to the thread_desc that Bill uses. The static
functions of
> Bill's interface are instead free functions. Also, no reference
> or smart pointers are used in this version.
> namespace boost {
> typedef implementation-defined thread;
> bool operator==(const thread&, const thread&);
> bool operator!=(const thread&, const thread&);
> template <class Function>
> thread create_thread(const Function&);
> template <class Function, class Arg>
> thread create_thread(const Function&, const Arg&);
> void join_threads();
> void join_thread(thread);
> thread thread_self();
> void sleep_thread(const xtime&);
> void yeild();
> }

This suffers from the name problem originally brought up by Beman.
The "thread" type in the above design isn't really a thread. It's a
thread id/descriptor/handle/reference. Further, since the
create_thread() methods return a "thread" object the thread type must
be copyable, and this *is* going to require ref-counting on some
platforms (pthreads, unless you include a detach_thread() method
which is going to change the overall semantics and effect other
ports) or some other reference management scheme on others
(WinThreads, where calls to DuplicateHandle() and CloseHandle() are
just an OS variation on ref-counting). Passing in a
pointer/reference to the thread object in create_thread() would
remove the need for the type to be copyable, but then we must deal
with issues of the lifetime of the actual thread (if I reuse a thread
object in another call to create_thread() what happens to the
previous and possibly still running thread?).

Other than these nits, this is just the design I spoke of with all
static methods, only with the syntax changed to free functions. The
free functions may be easier to deal with for end users, but it will
complicate the implementation. Either all data members must be made
public, or the methods must be made friends. Both are questionable
in an OO design (though you can argue that C++ supports non-OO design
and that such a design may be best here... but if you do so you'll
have to be ready to back the decision up when other programmers get a
gander at the design).

Bill Kempf

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