On 23/04/2013, at 12:04 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 22/04/2013, at 8:39 PM, Luke Daley <luke.da...@gradleware.com> wrote: > >> https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/execution/taskgraph/ParallelTaskPlanExecutor.java#L69 >> >> What's the reasoning behind this? >> >> If there is a reason to only allow a max of 4, shouldn't we warn the user >> that we have reduced the number of threads relative to their request? > > There's no good reason. Want to remove it? Done, for 1.7 (http://issues.gradle.org/browse/GRADLE-2760). If the user request --parallel-threads=100 but we cap it to 8 because there are only 8 projects, I think we should let the user know this has happened. That or we rename the flag to --max-parallel-threads. But, if we are going to be doing any renaming we should change it to --max-execution-threads as I think it's safe to assume that if you are sizing a set of threads then there is parallelism involved and what it would be better to have what the threads are actually going to be used for in the name. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
