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

Dev/toddgrun/request concurrency #66767

Merged
merged 23 commits into from
Feb 13, 2023

Conversation

ryanbrandenburg
Copy link
Contributor

This is a descendent of #66727 to try to take some work on the CLaSP core off of Todd's plate. @ToddGrun is welcome to cherry-pick my commits off here, rework them or we came merge this one instead, whatever works in the end.

Mostly what I've done is just to add a unit test as requested by DavidB.

ToddGrun and others added 17 commits February 6, 2023 14:57
…utionQueue.

This replaces the MutatesServerState flag with a flag that indicates how the request should be treated. Specifically, I needed a mode where the request ensured that all prior pending requests had completed before processing.
Remove an IsCancellationRequested check.
Throw some InvalidOperationExceptions based on unreachable conditions.
…, using NoThrowAwaitableInternal, and slightly different exception handling
…b.com:ToddGrun/roslyn into dev/toddgrun/RequestConcurrency
@ToddGrun
Copy link
Contributor

ToddGrun commented Feb 9, 2023

I'd vote we just move forward with this one, the other one is a bit of a mess.

@ryanbrandenburg ryanbrandenburg marked this pull request as ready for review February 9, 2023 22:12
@ryanbrandenburg ryanbrandenburg requested a review from a team as a code owner February 9, 2023 22:12
@ryanbrandenburg
Copy link
Contributor Author

CC @dibarbet, @CyrusNajmabadi, @jasonmalinowski, and @davidwengier. Since they reviewed the parent of this PR.

@ryanbrandenburg
Copy link
Contributor Author

My previous strategy for the ExecuteAsync_WithCancelInProgressWork_CancelsInProgressWorkWhenMutatingRequestArrives test won't work because we wrap the tasks in a Task.Run. So we're guaranteed that the handler will be exited, but not that the Task returned by requestExecutionQueue.ExecuteAsync is Completed or cancelled. So I changed it to a negative test. IE, I added a debug-assert which will fail if there are ever still items in the "InProgress" list when we try to start the mutating request. Not my favorite strategy, but the alternative seemed to be to re-work the code purely for the sake of this test, which seemed worse.

@ToddGrun
Copy link
Contributor

@dibarbet @CyrusNajmabadi @jasonmalinowski and @davidwengier

I've abandoned the old PR in favor of this one, can y'all take a look at this one sometime early this week? If I'm going to have any chance of getting the work done on my side in preview 2, I'll need this available fairly soon.

{
// Explicitly ignore this exception as this can occur during the CreateLinkTokenSource call, and means one of the
// linked cancellationTokens has been cancelled.
}
Copy link
Member

Choose a reason for hiding this comment

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

i feel like this needs to move to the place where we make the linked token. i think we should handle this clearly and specify the exact semantics of what that means at that location.

Copy link
Contributor

Choose a reason for hiding this comment

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

I debated on this when I made the change. The two alternates that I saw utilizing a tighter catch around the CreateLinkedTokenSource call were to catch and then either throw an OperationCanceledException or to catch and then do a continue to skip the rest of that iteration. I'll try out the latter and see if you like it better.

}

concurrentlyExecutingTaskCts.Dispose();
}, CancellationToken.None, TaskContinuationOptions.ExecuteSynchronously, TaskScheduler.Default);
Copy link
Member

Choose a reason for hiding this comment

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

nit: doc that CT.None here is very intentional as this code is absolutely necessary to run for clearnup regardless of how the task completed, and regardless if things were cancelled.

@@ -0,0 +1,138 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member

Choose a reason for hiding this comment

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

not reviewing. trusting it was copied minimally.

@ToddGrun ToddGrun merged commit 5cf6350 into dotnet:main Feb 13, 2023
@ghost ghost added this to the Next milestone Feb 13, 2023
@ryanbrandenburg ryanbrandenburg deleted the dev/toddgrun/RequestConcurrency branch February 15, 2023 19:31
@RikkiGibson RikkiGibson modified the milestones: Next, 17.6 P2 Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants