Skip to content
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

Pull reading of last storage subsystem out of lock (part2) #73295

Merged
merged 19 commits into from
May 2, 2024

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented May 1, 2024

Updates storage system to no longer be disposable.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels May 1, 2024
@CyrusNajmabadi CyrusNajmabadi changed the title Pull reading of last storage subsystem out of lock Pull reading of last storage subsystem out of lock (part2) May 1, 2024
private readonly CancellationTokenSource _shutdownTokenSource = new();

private readonly string _solutionDirectory;

private readonly SQLiteConnectionPoolService _connectionPoolService;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inlined this type. it really wasn't needed as a separate singleton type.

@@ -29,47 +29,17 @@ private async ValueTask FlushInMemoryDataToDiskIfNotShutdownAsync(CancellationTo
await PerformWriteAsync(_flushInMemoryDataToDisk, cancellationToken).ConfigureAwait(false);
}

private Task FlushWritesOnCloseAsync()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this intentionally went away. There is an ABWQ that is already flushign writes to disk. That will still continue working up until the point that the disposal token fires (which means VS is shutting down). We've always had the semantics that if we are shutting down, we strictly shut down, potentially losing some writes to disk (note: at worse we only ever lose writes in the las 0.5 seconds before shutdown).

Tthis is always safe to then skip. If we have any final writes, they'll either get flushed or not. If they do, great. If they don't, that's fine as well. That's because the persistent cache is only ever considered 'best effort'. 100% of featues taht use it can only use it as a place they try to store data into, but work 100% fine if those writes didn't happen. This will be detected the next tmie VS runs when a feature tries to erad the data, and simply goes "the data isn't htere, so i'll compute it".

ownershipLock.Dispose();
}

throw;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so much complex disposable logic that goes away.

@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review May 2, 2024 01:49
@CyrusNajmabadi CyrusNajmabadi requested a review from a team as a code owner May 2, 2024 01:49
@CyrusNajmabadi
Copy link
Member Author

@ToddGrun this is ready for review.

Copy link
Contributor

@ToddGrun ToddGrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@CyrusNajmabadi CyrusNajmabadi merged commit d8f3b0b into dotnet:main May 2, 2024
25 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone May 2, 2024
@CyrusNajmabadi CyrusNajmabadi deleted the noDispose branch May 2, 2024 14:29
@CyrusNajmabadi
Copy link
Member Author

@jasonmalinowski For review when you get back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants