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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-06 11:18:53

> From: "Wolfgang Bangerth" <bangerth_at_[hidden]>
>> 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 :-)
>
> I'm sure I'm never biased <wink>, and I tend to like your syntax better.
> However, I recognize what Bill is concerned about.  Let me suggest a
> compromise:
>
>   async_result<double> later = spawn(foo)(a, b, c);

Mustn't use the name spawn() here.  It implies a thread/process/what ever
has been spawned at this point, which is not the case.  Or has it (he says
later, having read on)?

>   ...
>   thread& t = later.thread();

The thread type will be Copyable and Assignable soon, so no need for the
reference.  Hmm... does this member indicate that spawn() above truly did
create a thread that's stored in the async_result?  Hmm... that would be
an interesting alternative implementation.  I'm not sure it's as "obvious"
as the syntax I suggested, as evidenced by the questions I've raised here,
but worth considering.  Not sure I care for "spawn(foo)(a, b, c)" though. 
I personally still prefer explicit usage of Boost.Bind or some other
binding/lambda library.  But if you want to "hide" the binding, why not
just "spawn(foo, a, b, c)"?

And if we go this route, should be remove the boost::thread constructor
that creates a thread in favor of using spawn() there as well?

   thread t = spawn(foo, a, b, c);

>   // do whatever with t
>   ...
>   double now = later.join();  // or later.get()
>
> You could also consider the merits of providing an implicit conversion
> from async_result<T> to T.

The merits, and the cons, yes.  I'll be considering this carefully at some
point.

> This approach doesn't get the asynchronous call wound up with the
> meaning of the "thread" concept.

If I fully understand it, yes it does, but too a lesser extent.  What I
mean by this is that the async_result hides the created thread (though you
do get access to it through the res.thread() syntax).  I found this
surprising enough to require careful thought about the FULL example you
posted to understand this.

-- 
William E. Kempf
wekempf_at_[hidden]