On 18 Jul 2014, at 10:40 am, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 6 Jul 2014, at 6:50 am, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > >> I'm pretty sure we don't want to expose a raw ExecutorService. We are pretty >> careful about exposing Gradle APIs that we have control over, rather than >> APIs that we don't have control over. > > I don’t think we talking about adding a public mechanism here, are we? - just > some internal mechanism to get parallel compilation working. > > Given this, ExecutorService isn’t a bad option to start with. Or something > that looks something like ExecutorService (a queue of Runnable things) that > we can grow into the public thing. Also, I think I’d aim this API at a more abstract ‘pieces of work’ view rather than a ‘run a child process’ view. Right now, we have 4 kinds of work we want to parallelise: 1. configuration action execution 2. task execution 3. test execution 4. native language compilation Only #4 is (directly) about forking a process. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
