From: "William E. Kempf" <[EMAIL PROTECTED]>
> > From: "Wolfgang Bangerth" <[EMAIL PROTECTED]>
> >> 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)?
It has.
> > ...
> > 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?
Yes.
> Hmm... that would be
> an interesting alternative implementation. I'm not sure it's as "obvious"
> as the syntax I suggested
Sorry, IMO there's nothing "obvious" about your syntax. It looks cumbersome
and low-level to me. Let me suggest some other syntaxes for async_result,
though:
async_call<double> later(foo, a, b, c)
or, if you don't want to duplicate the multi-arg treatment of bind(), just:
async_call<double> later(bind(foo, a, b, c));
...
...
double d = later(); // call it to get the result out.
I like the first one better, but could understand why you'd want to go with
the second one. This is easily implemented on top of the existing
Boost.Threads interface. Probably any of my suggestions is.
> as evidenced by the questions I've raised here,
Can't argue with user confusion I guess ;-)
> 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)"?
Mostly agree; it's just that interfaces like that tend to obscure which is
the function and which is the argument list.
> 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);
Good point. I dunno. I don't see a problem with the idea that
async_call<void> adds little or nothing to thread
> > 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).
That's what we mean by the terms "high-level" and "encapsulation" ;-)
> I found this
> surprising enough to require careful thought about the FULL example you
> posted to understand this.
Like I said, I can't argue with user confusion. Does the name "async_call"
help?
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
