Ok, now I vaguely remember seeing stuff about futures in your
Thrift code and wondering why it was there. I'm a little big
confused about what you want. If I understand correctly,
std.parallelism can already do it pretty easily, but maybe the
docs need to be improved a little to make it obvious how to.
All you have to do is something like this:
auto createFuture() {
auto myTask = task!someFun(); // Returns a _pointer_ to a
Task.
taskPool.put(myTask); // Or myTask.executeInNewThread();
// A task created with task() can outlive the scope it was
created in.
// A scoped task, created with scopedTask(), cannot. This is
safe,
// since myTask is NOT scoped and is a _pointer_ to a Task.
return myTask;
}
In this case myTask is already running using the execution
resources specified in createFuture(). Does this do what you
wanted? If so, I'll clarify the documentation. If not, please
clarify what you needed and the relevant use cases so that I can
fix std.parallelism.
On Wednesday, 3 October 2012 at 15:50:38 UTC, David Nadlinger
wrote:
On Wednesday, 3 October 2012 at 14:10:57 UTC, dsimcha wrote:
Unless we're using different terminology here, futures are
just std.parallelism Tasks.
No, std.parallelism.Tasks are not really futures – they offer
a constrained [1] future interface, but couple this with the
notion that a Task can be executed at some point on a TaskPool
chosen by the user. Because of this, I had to implement my own
futures for the Thrift async stuff, where I needed a future as
a promise [2] by an invoked entity that it kicked off a
background activity which will eventually return a value, but
which the users can't »start« or choose to »execute it
now«, as they can with Tasks.
If TaskPool had an execute() method which took a delegate to
execute (or a »Task«, for that matter) and returned a new
object which serves as a »handle« with wait()/get()/…
methods, _that_ would (likely) be a future.
David
[1] Constrained in the sense that it is only meant for
short-/synchronous-running tasks and thus e.g. offer no
callback mechanism.
[2] Let's not get into splitting hairs regarding the exact
meaning of »Future« vs. »Promise«, especially because C++11
introduced a new interpretation to the mix.
