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

> 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

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