Closed rpaquay closed 4 years ago
Note: The issue the result of a long standing bug that has been exposes by the Find In Files behavior.
During a "Find In Files", VS opens and closes each file (very quickly) in the Running Document Table maintained by VS. This results in VsChromium being notified of these files, which ends up sending a lot of "FileRegister"/"FileUnregister" requests for the same file almost immediately one after the other. The issue is that the server currently processes all requests concurrently in a thread pool, and sometimes requests are not processed in order.
Turns out this is worse than expected: With Find In Files running in multi-treaded mode in Visual Studio, some events that used to be fired on the UI thread only are now first from many threads concurrently. This breaks code that was not written to be thread safe. See https://github.com/chromium/vs-chromium/blob/master/src/VsChromium/Views/TextDocumentTable.cs#L90
Fixed in version 0.9.36
While investigating issue #61, another issue came up: after performing a "Find In Files" on a project of reasonable size (i.e. 100's of source files) and then closing the project, VsChromium still sees the "Project" as open and keeps them indexed until VS is restarted.