> > 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: [EMAIL PROTECTED]
www: http://www.ticam.utexas.edu/~bangerth/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
