Keep the host solution pinned on the remote workspace side while performing an inline-rename session#62854
Conversation
| var taskCompletionSource = new TaskCompletionSource<bool>(); | ||
| cancellationToken.Register(() => taskCompletionSource.TrySetCanceled(cancellationToken)); | ||
|
|
||
| await taskCompletionSource.Task.ConfigureAwait(false); |
There was a problem hiding this comment.
this is the sneaky part. the call from the host to OOP gets here and will block until the entire operation is finally canceled. Because we're inside RunServiceAsync that means we're pinning 'solution' in our internal cache attached to 'solutionChecksum'. So all successive calls to that checksum will see that solution.
There was a problem hiding this comment.
Do we need to hold onto a thread for this, or does this yield until the task completion source triggers?
There was a problem hiding this comment.
the latter. there's technically no threads here either (which is good). This is the idea behind a TaskCOmpletionSource, it's a way to get a task that you programatically control the completion of (either giving it a result, an exception, or cancellation).
Revert "Merge pull request #62854 from CyrusNajmabadi/renameOOP5"
Inline rename needs to first sync over the solution to OOP to find all the locations to update. Then as a user is typing the new name, we need to issue requests to OOP to determine what edits to make and what conflicts each of the new names they're trying may cause.
This is problemaitc with our current architecture because we have the following set of operations:
Because 4 and 5 S1 can be dropped. This gets worse as steps 3-5 repeat as the user is typing a new name, so it becomes almost certain that solution snapshot S1 will go away on OOP. THat means that each call to 5 much resync S1 (which is cheap) and then recompute things like compilations for all the projects involved in the rename operation (which is expensive).
Augments the above with the following steps:
After step 1: After session starts, inline-rename calls over to OOP and asks it to pin solution S1.
End: WHen the session ends, we let OOP know it can release S1.
By doing this we ensure that S1 never drops during all the repeats of steps 3-5. This keeps it available in OOP and ensures we don't drop expensive compilations.