-
-
Notifications
You must be signed in to change notification settings - Fork 407
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
is not disposing of CancellationTokenSource in ToCancellationToken a problem? #4611
Comments
It does sound like it should be disposed. This extension method can't do it, so it is the responsibility of any code using the token. It will be interesting to see if all the places it is used are in code where dispose is an option. If not, we'll have to consider removing the option. Hopefully that's not an issue, as it should be fine in things like data portal proxies and other DI-provided services. My one concern is if this has crept into the async rules engine, as none of those things are currently disposable (afaik). |
The services don't have to be disposable to use the cts. But we should make sure to dispose it in our own code. |
…ernalize them in v10) Add new method ToCancellationTokenSource and dispose the source correctly. Fixes #4611
* Make ToCancellationToken and containing class obsolete (so we can internalize them in v10) Add new method ToCancellationTokenSource and dispose the source correctly. Fixes #4611 * Revert unnecessary await
Make Csla internal visible to Csla.Blazor for reuse Fixes #4611
given CancellationTokenSource is disposable. is it a problem to not have it being disposed?
https://learn.microsoft.com/en-us/dotnet/standard/threading/cancellation-in-managed-threads
The text was updated successfully, but these errors were encountered: