-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make SDK resolution a service #2847
Conversation
BuildEventContext.InvalidTaskId)); | ||
BuildEventContext.InvalidTaskId), | ||
sdkResolverService, | ||
_requestEntry.Request.SubmissionId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: indenting
|
||
/// <summary> | ||
/// Resolves the specified SDK. | ||
/// </summary> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a remark here about locking? This does quite a bit of implicit thread synchronization where I would probably expect to see locks. A comment about that could help make it more obvious when locks are taken via the concurrent dictionaries.
private void HandleRequest(int node, SdkResolverRequest request) | ||
{ | ||
// Start the background thread which will process queued requests if it has not already been started. | ||
lock (_lockObject) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lock [](start = 12, length = 4)
Duplicate the if (_requestHandler == null)
to avoid locking
…at was resolved Add unit tests
@@ -12,6 +12,7 @@ | |||
|
|||
namespace Microsoft.Build.Engine.UnitTests.BackEnd | |||
{ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can these be adapted? Or delete the file if not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My next commit has renamed and updated these tests
Evaluation: Time (ms)
Evaluation: Memory (bytes)
Build: Time (ms)
Build: Memory (bytes)
|
…ImportsAreInPreprocessedOutput by using TestEnvironment to mock SDK resolution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the escape hatch for caching and looks good to me.
A singleton instance handles all resolution. A service hosted in the main node handles build related evaluation on the main node and a service hosted in the out-of-proc node sends requests to the main node for processing.
A cache exists on the main node so that requests are only resolved once per build. The out-of-proc node also caches responses so that an SDK is only resolved once.
Non-build evaluations are not cached and could be slow since there is no way to know if two evaluations are related.
Address the first step in #2803