Boost logo

Boost :

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
> > open for debate, but I find that most of the time it's not an
> > return that you need, so the whole C based concept of returning an
> > integer is flawed and serves little purpose. But that's *MY*
> > 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);
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
> > two differing semantics. When would it ever be valid to wait for
> > 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

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