openMP

[dsimcha]

Ok, I think I see where you're coming from here.  I've replied to 
some points below just to make sure and discuss possible 
solutions.

On Thursday, 4 October 2012 at 16:07:35 UTC, David Nadlinger 
wrote:
> On Wednesday, 3 October 2012 at 23:02:25 UTC, dsimcha wrote:

> Because you already have a system in place for managing these 
> tasks, which is separate from std.parallelism. A reason for 
> this could be that you are using a third-party library like 
> libevent. Another could be that the type of workload requires 
> additional problem knowledge of the scheduler so that different 
> tasks don't tread on each others's toes (for example 
> communicating with some servers via a pool of sockets, where 
> you can handle several concurrent requests to different 
> servers, but can't have two task read/write to the same socket 
> at the same time, because you'd just send garbage).
>
> Really, this issue is just about extensibility and/or 
> flexibility. The design of std.parallelism.Task assumes that 
> all values which "becomes available at some point in the 
> future" are the product of a process for which a TaskPool is a 
> suitable scheduler. C++ has std::future separate from 
> std::promise, C# has Task vs. TaskCompletionSource, etc.

I'll look into these when I have more time, but I guess what it 
boils down to is the need to separate the **abstraction** of 
something that returns a value later (I'll call that 
**abstraction** futures) from the **implementation** provided by 
std.parallelism (I'll call this **implementation** tasks), which 
was designed only with CPU-bound tasks and multicore in mind.

On the other hand, I like std.parallelism's simplicity for 
handling its charter of CPU-bound problems and multicore 
parallelism.  Perhaps the solution is to define another Phobos 
module that models the **abstraction** of futures and provide an 
adapter of some kind to make std.parallelism tasks, which are a 
much lower-level concept, fit this model.  I don't think the 
**general abstraction** of a future should be defined in 
std.parallelism, though.  std.parallelism includes 
parallelism-oriented things besides tasks, e.g. parallel map, 
reduce, foreach.  Including a more abstract model of values that 
become available later would make its charter too unfocused.

>
> Maybe using the word "callback" was a bit misleading, but it 
> callback would be invoked on the worker thread (or by whoever 
> invokes the hypothetical Future.complete(<result>) method).
>
> Probably most trivial use case would be to set a condition 
> variable in it in order to implement a waitAny(Task[]) method, 
> which waits until the first of a set of tasks is completed. 
> Ever wanted to wait on multiple condition variables? Or used 
> select() with multiple sockets? This is what I mean.

Well, implementing something like ContinueWith or Future.complete 
for std.parallelism tasks would be trivial, and I see how waitAny 
could easily be implemented in terms of this.  I'm not sure I 
want to define an API for this in std.parallelism, though, until 
we have something like a std.future and the **abstraction** of a 
future is better-defined.

>
> For more advanced/application-level use cases, just look at any 
> use of ContinueWith in C#. std::future::then() is also proposed 
> for C++, see e.g. 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3327.pdf.
>
> I didn't really read the the N3327 paper in detail, but from a 
> brief look it seems to be a nice summary of what you might want 
> to do with tasks/asynchronous results – I think you could 
> find it an interesting read.

I don't have time to look at these right now, but I'll definitely 
look at them sometime soon.  Thanks for the info.