[concurrency-interest] forkjoin.ParallelArray and friends
tim at peierls.net
Mon Aug 27 20:41:15 EDT 2007
On 8/27/07, Doug Lea <dl at cs.oswego.edu> wrote:
> Neal Gafter wrote:
> > I think the whole API should be interface-based. For example, I think
> > the results of a.withMapping() should be the ParallelArray interface or
> > some subtype.
> We debated this. I think the current form is an OK compromise
> between too little and too much abstraction. For example, to
> properly generalize ParallelArray as an interface, you'd also need to
> somehow generalize ForkJoinExecutor into something that would allow
> say alternate ParallelArray implementations via say GPU parallelism.
> Which then gets you into lots of bulky layers of interfaces and
> factories before you can get anything done. Maybe someday we will
> need such a thing, but if so, it can be retrospectively abstracted.
I argued strongly for an interface-based API, but I've come to accept Doug's
Seriously, after playing with the current API for a bit, it seems to me that
we need a lot more experience using these FJ creatures before trying to
device interface-based APIs that are implemented in terms of them. Classes
come and go; interfaces are forever.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest