Introduce cross-process resource management for tasks #5859
Conversation
Got straightforward unit tests working. Added null check and cached the Semaphore.
…rces consumed but want to start a task
This reverts commit f60c66a.
This reverts commit 3c7a3f8.
This should alleviate hangs that were happening as a result of leaks that happened when MSBuild/CallTarget got a resource, then we started building other projects.
…hreads yielded + reacquiring)
Otherwise, we can deadlock: outer task gets a resource, (logically) yields to build other projects; they block on getting a resource.
…th Yielded tasks busy
| } | ||
| else | ||
| { | ||
| // Resource release is a one-way call, no response is expected. We release the cores as instructed |
There was a problem hiding this comment.
There could be an issue if the ReleaseCores call for a process that uses a lot of cores gets lost somehow. I'm wondering if, in addition to being able to release cores, there should be an auto-release after a certain amount of time. Perhaps the scheduler pings the task, and if it responds that it still needs cores, it resets it; otherwise, it reclaims them?
There was a problem hiding this comment.
There are countless ways a task can hang the build. Yes, the new API needs to be used carefully. With great power comes great responsibility, as they say. What you are suggesting sounds too complicated and it would not prevent all hangs. I can imagine tasks would use a hard-coded "yes" when asked if they still need cores and pass int.MaxValue for timeout.
There was a problem hiding this comment.
My only reservation is that there aren't a lot of features to prevent users from shooting themselves in the foot, especially in unusual circumstances with highly oversubscribed machines and/or low-priority builds, but I don't think that should hold you back. Thanks for picking this up and driving it through!
| /// <summary> | ||
| /// Retrieves the <see cref="IBuildEngine9" /> version of the build engine interface provided by the host. | ||
| /// </summary> | ||
| public IBuildEngine9 BuildEngine9 => (IBuildEngine9)BuildEngine; |
There was a problem hiding this comment.
As I mentioned in the meeting, I slightly prefer reusing IBuildEngine8, but this is fine.
Forgind
added
the
merge-when-branch-open
Add
RequestCoresandReleaseCoresAPIs toIBuildEngine8.These APIs can advise a task that wishes to do work with its own internal parallelism. The task can request as many (abstracted) CPU cores as it desires, and the MSBuild engine will keep track of how many have been requested and prevent the machine from being completely overloaded.
Since this is advisory only, existing tasks will be unaffected. The Visual C++ tasks plan to opt into this.
See
resource-management.mdfor more design and implementation details.Fixes #74