Re: Boost.Threads - thread_desc concept

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 
counting
> 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