You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement an ability to configure a max # of concurrent processes. This should work something like a thread executor (in fact could probably be implemented as such).
The idea here is that the build may submit N processes to be executed, but Gradle will only execute M processes at a time. As a processes completes, it's return/execution result is stored and a new process is grab from the queue and executed until there are no more remaining.
The API to to build should not change. Normal forking and joining should exist.
Requesting execution of the processes should return immediately, even if the process in queued for execution. This will likely require a new implementation of ProcessHandle since the a concrete process won't exist yet for those queued.
Additionally waiting for completion of queued processes should wait for only those processes to be drained from the queue.
THOUGHT Should any credence be placed on ordering of the processes within the queue? Do we need a priority? Should processes that are being waited on have precedence to be popped from the queue ahead of those not being waited on?
The text was updated successfully, but these errors were encountered:
Implement an ability to configure a max # of concurrent processes. This should work something like a thread executor (in fact could probably be implemented as such).
The idea here is that the build may submit N processes to be executed, but Gradle will only execute M processes at a time. As a processes completes, it's return/execution result is stored and a new process is grab from the queue and executed until there are no more remaining.
The API to to build should not change. Normal forking and joining should exist.
Requesting execution of the processes should return immediately, even if the process in queued for execution. This will likely require a new implementation of ProcessHandle since the a concrete process won't exist yet for those queued.
Additionally waiting for completion of queued processes should wait for only those processes to be drained from the queue.
THOUGHT Should any credence be placed on ordering of the processes within the queue? Do we need a priority? Should processes that are being waited on have precedence to be popped from the queue ahead of those not being waited on?
The text was updated successfully, but these errors were encountered: