{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/vs-threading/issues/434","repository_url":"https://api.github.com/repos/Microsoft/vs-threading","labels_url":"https://api.github.com/repos/Microsoft/vs-threading/issues/434/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/vs-threading/issues/434/comments","events_url":"https://api.github.com/repos/Microsoft/vs-threading/issues/434/events","html_url":"https://github.com/Microsoft/vs-threading/issues/434","id":391854962,"node_id":"MDU6SXNzdWUzOTE4NTQ5NjI=","number":434,"title":"Provide an option so that SwitchToMainThreadAsync will check for cancellation prior to executing on Main thread.","user":{"login":"CyrusNajmabadi","id":4564579,"node_id":"MDQ6VXNlcjQ1NjQ1Nzk=","avatar_url":"https://avatars3.githubusercontent.com/u/4564579?v=4","gravatar_id":"","url":"https://api.github.com/users/CyrusNajmabadi","html_url":"https://github.com/CyrusNajmabadi","followers_url":"https://api.github.com/users/CyrusNajmabadi/followers","following_url":"https://api.github.com/users/CyrusNajmabadi/following{/other_user}","gists_url":"https://api.github.com/users/CyrusNajmabadi/gists{/gist_id}","starred_url":"https://api.github.com/users/CyrusNajmabadi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/CyrusNajmabadi/subscriptions","organizations_url":"https://api.github.com/users/CyrusNajmabadi/orgs","repos_url":"https://api.github.com/users/CyrusNajmabadi/repos","events_url":"https://api.github.com/users/CyrusNajmabadi/events{/privacy}","received_events_url":"https://api.github.com/users/CyrusNajmabadi/received_events","type":"User","site_admin":false},"labels":[{"id":455627242,"node_id":"MDU6TGFiZWw0NTU2MjcyNDI=","url":"https://api.github.com/repos/Microsoft/vs-threading/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2018-12-17T19:22:25Z","updated_at":"2018-12-17T20:04:36Z","closed_at":null,"author_association":"NONE","body":"For more context, see thread here: https://github.com/dotnet/roslyn/pull/31787\r\n\r\nSpecifically starting here: https://github.com/dotnet/roslyn/pull/31787#issuecomment-447502124\r\n\r\nTLDR: Rosly switched some explicit usages of TPL+SyncContexts to use JTF for switching to the UI thread.  This ended up causing crashes due to Roslyn depending on TPL behavior that JTF doesn't provide.  Specifically, roslyn often 'chains' tasks along.  For example, it might have the following sort of chain:\r\n\r\n```\r\nTask1(ui thread) -> ContinuesWith -> Task2 (expensive BG code) -> ContinuesWith -> Task3 (ui thread)\r\n```\r\n\r\nThis is common for us so that we can update shared state *and* often let teh rest of VS know about something important in a STA manner.\r\n\r\nWhiel these tasks are running we are still processing inputs and, on the UI thread, we may decide to cancel this chain of work.  For example, while Task2 is executing, we may end up cancelling on hte UI thread because of something the user did.  With TPL, we had behavior whereby even if TPL decided Task3 was to run (because, say, Task2 had completed and things had been scheduled), once Task3 actually executed, it would always see the cancellation made on the UI thread.  This happened automatically by TPL.  Before starting to run Task3, it would do a final cancellation check and would then throw in this case.  In essence, we depended on the TPL behavior that any changes made on one thread would be seen by later tasks that would run on that thread.  Since we canceled on hte UI thread, it was certain that any other tasks intended ot run on the UI thread would always see that cancellation.\r\n\r\nJTF does not have this behavior.  Even if we cancel on the UI thread, JTF will allow a descendant task to both switch to the UI thread and continue running.  This broke the expected behavior we god from TPL.\r\n\r\nFortunately, in the linked issue, this caused a crash, helping to track this down.  But, far more often, when roslyn has encountered some sort of race like this, it has led to data corruption which often just leads to broken behavior for the user.  Usually because data is updated that should not be updated.\r\n\r\n--\r\n\r\nThe ask here is for JTF to have an option on these methods to behave like TPL.  Specifically, one should be able to ask it to switch to the UI thread, and have it check+throw once it gets to the UI thread if previous code on teh UI thread canceled that exception. \r\n\r\nWhile i would like this to be the default, it is recognized that this could be considered a fairly drastic change in behavior that would negatively affect others."},"comment":{"url":"https://api.github.com/repos/Microsoft/vs-threading/issues/comments/447980069","html_url":"https://github.com/Microsoft/vs-threading/issues/434#issuecomment-447980069","issue_url":"https://api.github.com/repos/Microsoft/vs-threading/issues/434","id":447980069,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0Nzk4MDA2OQ==","user":{"login":"sharwell","id":1408396,"node_id":"MDQ6VXNlcjE0MDgzOTY=","avatar_url":"https://avatars1.githubusercontent.com/u/1408396?v=4","gravatar_id":"","url":"https://api.github.com/users/sharwell","html_url":"https://github.com/sharwell","followers_url":"https://api.github.com/users/sharwell/followers","following_url":"https://api.github.com/users/sharwell/following{/other_user}","gists_url":"https://api.github.com/users/sharwell/gists{/gist_id}","starred_url":"https://api.github.com/users/sharwell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sharwell/subscriptions","organizations_url":"https://api.github.com/users/sharwell/orgs","repos_url":"https://api.github.com/users/sharwell/repos","events_url":"https://api.github.com/users/sharwell/events{/privacy}","received_events_url":"https://api.github.com/users/sharwell/received_events","type":"User","site_admin":false},"created_at":"2018-12-17T20:04:36Z","updated_at":"2018-12-17T20:04:36Z","author_association":"MEMBER","body":"@CyrusNajmabadi It's not vs-threading that's violating KISS here. Roslyn using application of CancellationToken as a basis for algorithm correctness is already too complex; vs-threading operates under even simpler considerations. "}}
{"actor":{"display_login":"sharwell"}}