openMP

[dsimcha]

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.