Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Productize ManualResetValueTaskSource #26899

Closed
stephentoub opened this issue Jul 22, 2018 · 10 comments
Closed

Productize ManualResetValueTaskSource #26899

stephentoub opened this issue Jul 22, 2018 · 10 comments
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Threading
Milestone

Comments

@stephentoub
Copy link
Member

As called out in dotnet/corefx#29468, we should design/expose ManualResetValueTaskSource{Logic} (https://github.com/dotnet/corefx/blob/master/src/Common/tests/System/Threading/Tasks/Sources/ManualResetValueTaskSource.cs), and potentially an auto-reset equivalent. The manual-reset variety is likely to be used by async iterators generated by the C# compiler, and the auto-reset variety would be needed if we wanted to replace implementations already in use in corefx (e.g. in Socket).

@stephentoub
Copy link
Member Author

@AndreasHeisel
Copy link

Hello @stephentoub,

I have investigated ManualResetValueTaskSource if it can help avoiding allocations in my code. It is an awesome piece of code but I do miss one thing:

TaskCompletionSource has a constructor that accepts a TaskCreationOptions value. The one I miss is RunContinuationsAsynchronously - for the same reasons it was added to TaskCreationOptions.

https://blogs.msdn.microsoft.com/pfxteam/2015/02/02/new-task-apis-in-net-4-6/

@stephentoub
Copy link
Member Author

TaskCompletionSource has a constructor that accepts a TaskCreationOptions value. The one I miss is RunContinuationsAsynchronously

The ManualResetValueTaskSourceCore from https://github.com/dotnet/corefx/issues/32664 has a RunContinuationsAsynchronously property.

@AndreasHeisel
Copy link

Ok, my fault. I used an older version. Thank you

@stephentoub
Copy link
Member Author

😄

@AndreasHeisel
Copy link

Is there a way to see if GetResult() was called? I mean how do I know when it is safe to call Reset() and when I must allocate a new ManualResetValueTaskSource{?

@stephentoub
Copy link
Member Author

You can track that yourself in whatever code wraps this struct. Your wrapper is what actually implements the interface, and thus it's actually your GetResult method that's called (and you then call he struct's GetResult), so you can keep track of that.

@AndreasHeisel
Copy link

So I have to use ManualResetValueTaskSourceLogic to track it. The class version ManualResetValueTaskSource doesn't track. Correct?

@stephentoub
Copy link
Member Author

The class version ManualResetValueTaskSource doesn't track

We're not currently planning to ship the class version. If we do, we could decide whether to track it or not.

@AndreasHeisel
Copy link

Understood, thank you

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Threading
Projects
None yet
Development

No branches or pull requests

3 participants