Boost logo

Boost :

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]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk