-
Notifications
You must be signed in to change notification settings - Fork 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
Be resilient to asset-cache mutating while retrieving assets from the host #72599
Conversation
In a perf fix I made last week, I assumed _assetCache wouldn't change underneath me during execution of SynchronizeAssetsAsync. That assumption is not true. Now, if the asset cache changes such that the missingChecksums array is no longer sufficient to hold all missing checksums, then grow the array capacity such that it can hold additional entries that might now be missing.
…ynchronizeAssetsAsync' into assets
@@ -29,39 +29,34 @@ internal sealed partial class AssetProvider(Checksum solutionChecksum, SolutionA | |||
private readonly SolutionAssetCache _assetCache = assetCache; | |||
private readonly IAssetSource _assetSource = assetSource; | |||
|
|||
private T GetRequiredAsset<T>(Checksum checksum) |
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.
this operation si fundamentally not supported. there is no way, ever, to ensure that a checksum you're asking for is actually in the asset provider (unles sit was pinned. but that's a vanishingly small number of cases).
@@ -136,24 +131,60 @@ public async ValueTask SynchronizeProjectAssetsAsync(ProjectStateChecksums proje | |||
missingChecksumsCount = 0; | |||
foreach (var checksum in checksums) | |||
{ | |||
if (!_assetCache.TryGetAsset<object>(checksum, out _)) |
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.
view with whitespace off.
@@ -47,14 +51,17 @@ public async ValueTask SynchronizeSolutionAssetsAsync(Checksum solutionChecksum, | |||
|
|||
solutionChecksumObject.AddAllTo(checksums); | |||
checksums.Remove(solutionChecksumObject.Checksum); | |||
await _assetProvider.SynchronizeAssetsAsync(assetHint: AssetHint.None, checksums, cancellationToken).ConfigureAwait(false); | |||
await _assetProvider.SynchronizeAssetsAsync(assetHint: AssetHint.None, checksums, results: null, cancellationToken).ConfigureAwait(false); |
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.
so we could pass a dictionary here that we then read in below. but i didn't feel like it was worth it. the data will normally always stay in the asset provider. and the cahnge below to use GetAssetAsync will normally find it, or rarely then go and reretrieve it in the rare unlucky case. that saves a potentially large dictionary alloc here (even if pooled).
|
||
await _assetProvider.SynchronizeAssetsAsync( | ||
assetHint: projectChecksum.ProjectId, checksums, cancellationToken).ConfigureAwait(false); | ||
assetHint: projectChecksum.ProjectId, checksums, results: null, cancellationToken).ConfigureAwait(false); |
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.
same here.
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.
The asset cache serves more as a weak cache of data, storing information on the server in the hopes it will be useful at future points in time. It contains a GC thread that wakes up every minute or so and flushes data it thinks isn't needed anymore. Due to that, access to the data from the cache itself is fundamentally racey and should not be trusted.