Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 05 21:07

    AArnott on main

    Crash the process on unexpected… Merge pull request #846 from AA… (compare)

  • May 05 21:07
    AArnott closed #846
  • May 05 16:02
    AArnott unlabeled #845
  • May 05 16:02

    AArnott on main

    Remove unnecessary warning supp… Merge pull request #845 from AA… (compare)

  • May 05 16:02
    AArnott closed #845
  • May 05 15:52
    AArnott labeled #845
  • May 05 15:48
    AArnott edited #846
  • May 05 15:48
    AArnott edited #846
  • May 05 15:47
    AArnott review_requested #846
  • May 05 15:47
    AArnott review_requested #846
  • May 05 15:47
    AArnott review_requested #846
  • May 05 15:47
    AArnott review_requested #846
  • May 05 15:47
    AArnott review_requested #846
  • May 05 15:47
    AArnott labeled #846
  • May 05 15:47
    AArnott assigned #846
  • May 05 15:47
    AArnott opened #846
  • May 05 15:47
    AArnott milestoned #846
  • May 05 15:41
    AArnott assigned #845
  • May 05 15:41
    AArnott milestoned #845
  • May 05 15:41
    AArnott opened #845
Sam Harwell
@sharwell
@AArnott Do you have more information about when .NET inlines continuations that don't have ExecuteSynchronously set explicitly?
Andrew Arnott
@AArnott
@sharwell don't submit PRs at this point. Our CONTRIB doc mentions this. We can't accept external PRs at the moment. However if interest is significant enough (from folks like yourself) we will prioritize getting that changed.
Sam Harwell
@sharwell
I did see that but thanks for the heads-up
Andrew Arnott
@AArnott
I'm not sure. I just know that that flag is a suggestion, but TPL may or may not inline the continuation in spite of its presence or absence.
Sam Harwell
@sharwell
PRs also serve to better demonstrate some of the items I've mentioned even if they can't be accepted directly
Andrew Arnott
@AArnott
It certainly can help encourage inlining. I'm not against the flag. I'm just pointing out that it may not actually win us anything if inlining already tends to happen.
re: PRs: True. But then we might get into this uncomfortable world of "I'm rejecting your PR, but I'm going to copy your code into my own commits". So I suppose if you want to show code, use a gist and keep it gist-y. Don't tempt me to reuse your code. :)
Sam Harwell
@sharwell
I'm like :expressionless: each place I read Till which is only 1 character shorter than Until
Andrew Arnott
@AArnott
Are you referring to test names?
Oh, perhaps JoinTillEmpty?
Sam Harwell
@sharwell
That's the one!
Andrew Arnott
@AArnott
That's feedback I would have been happy to respond to before the API was released. Too bad we didn't originally develop this in an OSS way, eh?
Sam Harwell
@sharwell
:question: Does JoinableTaskFactory [need to] propagate the ExecutionContext? I notice that it doesn't implement ICriticalNotifyCompletion, but it also seems to assume the caller is responsible for propagating the execution context.
Andrew Arnott
@AArnott
@sharwell it sounds like your question is about the type returned from SwitchToMainThreadAsync, is that right? If so, no, custom awaiters don't have to worry about ExecutionContext propagation. The runtime/BCL takes care of that for us.
Sam Harwell
@sharwell
:+1:
Sam Harwell
@sharwell
I'm having trouble running the tests inside Visual Studio. Is there something special I need to do other than what's listed in the contributing file for building?
------ Discover test started ------
[xUnit.net 00:00:00.3651571] Skipping: Microsoft.VisualStudio.Threading.Analyzers.Tests (could not find dependent assembly 'Microsoft.VisualStudio.Threading.Analyzers.Tests, Version=15.0.0')
========== Discover test finished: 0 found (0:00:00.4765306) ==========
Andrew Arnott
@AArnott
try launching VS from a Developer Command Prompt after setting the env var: signtype=mock
Then do a rebuild within VS and run tests
If that works, we should update the contrib doc.
It has to do with "public signing" for assembly strong names and the fact that vstest.console defaults to shadow copying, which breaks for public signed assemblies.
Sam Harwell
@sharwell
set SIGNTYPE=mock
devenv
Still no success after a rebuild all
Andrew Arnott
@AArnott
hmmmm... do the tests run from the command line? Can you take a look at the appveyor.yml file to see if it's doing anything that you're not?
bluetarpmedia
@bluetarpmedia
Anyone still use this room or is it archived? :)
Andrew Arnott
@AArnott
ya, we're still here.
bluetarpmedia
@bluetarpmedia
Cool! Well first I should say thanks very much for JTF because it's really well designed and as an application developer exactly what you want.
I was playing around with some code where I expected a VSTHRD010 warning but didn't get one. It was when calling IMenuCommandService.AddCommand on a thread other than the main/UI thread. VS appeared to deadlock. I knew (to the best of my knowledge) it needed the main thread, and the deadlock doesn't occur when switching to the main thread first. So I started playing with vs-threading to see if I could figure out how to get that warning with this interface.
bluetarpmedia
@bluetarpmedia
I discovered vs-threading.MembersRequiringMainThread.txt in both vs-threading (which is empty) and in VSSDK-Analyzers, and the mock version in the vs-threading tests. Is there a way to add IMenuCommandService to that list? Or is that text file even the right place to add it?
Andrew Arnott
@AArnott
@bluetarpmedia Yes, the MembersRequiringMainThread.txt file is where you should add the WPF/WinForms or other APIs that require the main thread. If the APIs come with .NET (BCL) then we'd welcome a PR that adds it to vs-threading itself. For anything proprietary, you can add this file to your own project to add additional APIs.
bluetarpmedia
@bluetarpmedia
Thanks @AArnott
bluetarpmedia
@bluetarpmedia

@AArnott In the fire-and-forget issue we were discussing with Mads in the Community Toolkit repo, you said:

Forget comes from the vs-threading library and is ok for other apps to use -- but not for VS, since VS hosts the CLR and may tear it down before terminating the process.

I wanted to follow up on this because the Toolkit is using Forget() in a few places. I noticed that the Forget overload taking a Task in vs-threading is just an empty method:

public static void Forget(this Task? task)
{
}

Is the problem with using Forget in VS because of the ValueTask overloads? And therefore, if the async method is guaranteed to return Task, it would be okay to use Forget on it inside a VS extension?

bluetarpmedia
@bluetarpmedia
Just realised ValueTask isn't in the .NET Framework so doesn't apply to VS. So if Forget does nothing for plain Task, I guess you're saying that it does nothing to ensure the task gets joined before the CLR AppDomain is shutdown?