Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 14 04:41

    AArnott on v16.10

    Insert into 16.10 branch (compare)

  • May 14 04:41

    AArnott on main

    Insert into 16.10 branch Merge branch 'v16.10' (compare)

  • May 12 14:21

    AArnott on v16.10

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… Merge remote-tracking branch 'u… (compare)

  • May 12 14:21

    AArnott on main

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… Merge remote-tracking branch 'u… and 1 more (compare)

  • May 12 14:20

    AArnott on v16.9

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… (compare)

  • May 12 14:20
    AArnott closed #848
  • May 12 14:02
    AArnott milestoned #848
  • May 12 14:02
    AArnott assigned #848
  • May 12 14:02
    AArnott opened #848
  • May 11 19:21

    AArnott on main

    Update insertion branch (compare)

  • May 11 18:06

    lifengl on lifengl

    (compare)

  • May 11 18:06

    lifengl on main

    Use strong references for JTF d… Merge pull request #847 from mi… (compare)

  • May 11 18:06
    lifengl closed #847
  • May 11 18:05
    lifengl commented #847
  • May 10 17:55
    nbarbettini commented #584
  • May 10 15:51
    springy76 commented #584
  • May 08 19:58
    AArnott commented #584
  • May 07 20:24
    lifengl edited #847
  • May 07 20:22
    lifengl opened #847
  • May 07 07:44
    Bosch-Eli-Black closed #827
Sam Harwell
@sharwell
@AArnott :bug: Microsoft/vs-threading#75
Andrew Arnott
@AArnott
Nice catch.
Sam Harwell
@sharwell
@AArnott I think AsyncQueueTests.NoLockHeldForCancellationContinuation would benefit from an assertion at the end that the queue contains one item.
Andrew Arnott
@AArnott
Thanks. Please feel free to file issues for these suggestions (either an individual issues or one with a checklist of your suggestions) so I don't lose track of them in this stream of messages.
Sam Harwell
@sharwell
NP wasn't sure if you wanted small issues like that but they are easy to file
Andrew Arnott
@AArnott
Well, I normally wouldn't. But you tend to have a good level of insight. And ya, if you expect lots of small ideas, a single issue with a markdown checkbox list would probably be preferable.
Sam Harwell
@sharwell
Normally I would just submit pull requests but I'm mostly reviewing the code in the context of different project so issues it is for now :smile:
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?
Andrew Arnott
@AArnott
@bluetarpmedia ValueTask is available on .NET Framework, and you can see vs-threading supports it here.
Forget(Task) does nothing because it's only there to suppress analyzer warnings regarding a dropped task. Returning void from this method accomplishes that. The Forget(ValueTask) overload has to call Preserve because ValueTask needs to be awaited or turned into a task.
It's not great for VS to do fire-and-forget code. But most of the reason is internal to VS itself. It's extensions can probably get away with it because we don't shutdown the default appdomain in the shipping product--we only do so in internal testing where your extensions don't run. That's why I came to an agreement with Mads that he could go ahead and use it in his toolkit.
bluetarpmedia
@bluetarpmedia
aha, thanks for that!