Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 16:24:41

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Hi,
> 
> --- William Kempf <sirwillard_at_m...> wrote:
> > --- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> 
wrote:
> [A thread class to be derived from removed]
> 
> > This is the "thin wrapper" that I dislike.  Now we must derive 
from 
> > thread (or in other implementation, derive from runnable or some 
> > other suitably named secondary class) in order to be an "active 
> > object" and the active object is the only form of thread routine 
> > available.  A thread creation routine that truly took C++ into 
> > consideration would allow you to create a thread from any 
function or
> > any member function or even from some arbitrary functor.
> 
> Here is the version for functors and functions:
> 
>   template <typename Func>
>   struct function_thread: thread {
>     function_thread(Func func): m_func(func) {}
>     int do_run() { return m_func(); }
>   private:
>     Func m_func;
>   };
> 
>   template <typename Func>
>   void start_thread(Func func) {
>     function_thread<Func> *thread = new function_thread<Func>(func);
>     thread->run();
>   }

You're sort of on what I'd consider the "right track" here.  The 
proper (to me) approach would use a templated thread::create (static 
of course) that would allow for a (nearly) unlimited range 
of "routines" that can be called.  Again, think "slots for threads".  
The "type" of "routine" is open ended, and with careful design the 
parameters can be open ended and type safe as well.  I'm not sure if 
the return type should be open or required to be an integral type.  
It's not that complicated, and because we *ARE* wrapping pthreads the 
implementation winds up being similar, but the original wrapper still 
showed why I think we should not cloud our thinking with the pthread 
interface while defining ours.

At this point, I'm going to drop this sub-discussion because I don't 
think we're at a point to really be discussing the interface of the 
thread class.