Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-09 14:47:30

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> 
> > I've not included a return type currently.  That's something 
that's
> > open for debate, but I find that most of the time it's not an 
integer
> > return that you need, so the whole C based concept of returning an
> > integer is flawed and serves little purpose.  But that's *MY* 
opinion
> > and I'm more than willing to listen to arguments on this one.
> 
> it would be great to have some template based solution with join
> returning a pointer (NULL used as cancel indication). C++ thread
> object could be used to store the return value to avoid extra memory
> management.

Possibly doable, but very complicated.  I currently envision users 
using a function object to hold the result data, so there's no need 
for a return at all.

template <typename T>
struct call_with_result
{
   call_with_result(boost::function0<T>& func) : m_func(func) {}
   void operator()()
   {
      m_result = m_func();
   }
   T m_result;
   boost::function0<T> m_func;
};

call_with_result<foo> call(threadfunc);
boost::thread thrd(call);
thrd.join();
foo result = call.m_result;

A minimum of 2 extra lines for the caller, but it's fairly straight 
forward and easy to do.  Given that in my own personal experience you 
need a return from a thread only a VERY small fraction of the time 
this doesn't seem like much of an issue.  Again, though, I'm very 
open to debate, though if anything decided is going to require 
significant effort it's not likely to be included in the initial 
submission.  This is something that can be easily changed with out 
breaking user code at a later date.

> > > thread::join() and thread::wait_blabla()
> > > ^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^
> > >    *JOIN*          wait for begin of
> > > multiple calls     thread termination,
> > > (from multiple     does not guarantee
> > > threads) is OK.    that term. is completed
> > >                    on return.
> >
> > I don't totally follow you here.  I don't see why there's a need 
for
> > two differing semantics.  When would it ever be valid to wait for 
the
> > thread to "begin termination".
> 
> when you are interested in return value only and/or just
> want to know that thread start routine have returned or
> was interrupted by _exit/cancel and do not want to wait
> for end of thread termination (eventual cleanup handlers,
> tsd destructors,...; allowing it to run "in parallel"
> after you have got return value/control flow indication;
> you could even detach the thread afterwards...);

I'm not sure that any of these are valid reasons.  In Win32 the only 
resource not cleaned up before the return from WaitFor*() is the 
thread handle itself.  So I've seen the need for multiple calls 
to "join", but have not seen a need for this alternative "wait".

Bill Kempf