[boost] Re: A new boost::thread implementation?

From: Wolfgang Bangerth (bangerth_at_[hidden])
Date: 2003-02-05 18:29:12

> >     double d;
> >     thread<double> t = spawn(foo)(a,b,c);
> >     // do something else
> >     d = thread.return_value();
> 
> A solution like this has been proposed before, but I don't like it.  This
> creates multiple thread types, instead of a single thread type.  I think
> this will only make the interface less convenient, and will make the
> implementation much more complex.  For instance, you now must have a
> seperate thread_self type that duplicates all of thread<> except for the
> data type specific features.  These differing types will have to compare
> to each other, however.

Make the common part a base class. That's how the proposal I sent you does 
it :-)

> async_result<double> res;
> thread t(bind(res.call(), a, b, c));
> // do something else
> d = res.value();  // Explicitly waits for the thread to return a value?

This does the same, indeed. Starting a thread this way is just a little 
more complex (and -- in my view -- less obvious to read) than writing
  thread t = spawn(foo)(a,b,c);

But that's just personal opinion, and I'm arguably biased :-)

> Hopefully you're not duplicating efforts here, and are using Boost.Bind
> and Boost.Function in the implementation?

Actually it does duplicate the work, but not because I am stubborn. We 
have an existing implementation for a couple of years, and the present 
version just evolved from this. However, there's a second point: when 
starting threads, you have a relatively clear picture as to how long 
certain objects are needed, and one can avoid several copying steps if one 
does some things by hand. It's short anyway, tuple type and tie function 
are your friend here.

> Give me a couple of days to have the solution above implemented in the dev
> branch, and then argue for or against the two designs.

Sure. I'll be away next week, so there's plenty of time :-)

> >     thread<> t = spawn(foo)(a,b,c);
> >     t.yield ();    // oops, who's going to yield here?
> 
> You shouldn't really ever write code like that.  It should be
> thread::yield().  But even if you write it the way you did, it will always
> be the current thread that yields, which is the only thread that can.  I
> don't agree with seperating the interfaces here.

I certainly know that one shouldn't write the code like this. It's just 
that this way you are inviting people to write buglets. After all, you 
have (or may have in the future) functions
  t->kill ();
  t->suspend ();
Someone sees that there's a function yield() but doesn't have the time to 
read the documentation, what will he assume what yield() does?

If there's a way to avoid such invitations for errors, one should use it.

Regards
  Wolfgang

PS: Can you do me a favor and CC: me? I just get the digests of the 
mailing list and replying is -- well, tedious ;-)

-------------------------------------------------------------------------
Wolfgang Bangerth             email:            bangerth_at_[hidden]
                              www: http://www.ticam.utexas.edu/~bangerth/