Review undisposed resources used in async/multithreaded scenarios.
- Dominant language
- C#
- Stars
- 7.2k
- Forks
- 798
- PR merge metrics
- No merged PRs in 30d
Description
#### Bug
Library version: 5.0.0
All platforms.
There are several places in the code in which objects implementing `IDisposable` are created and never disposed. This typically happens in scenarios involving asynchronous or multithreaded operation. For example:
* [`Scheduler.AsyncInvocation._cts](https://github.com/dotnet/reactive/blob/fb2b69dd232bfa1415bcf09ccfd5ea2f6d4fb992/Rx.NET/Source/src/System.Reactive/Concurrency/Scheduler.Async.cs#L15)
* [`Scheduler.SchedulePeriodicStopwatch._resumeEvent`](https://github.com/dotnet/reactive/blob/fb2b69dd232bfa1415bcf09ccfd5ea2f6d4fb992/Rx.NET/Source/src/System.Reactive/Concurrency/Scheduler.Services.Emulation.cs#L339)
* [TaskPoolScheduler.PeriodicallyScheduledWorkItem._cts](https://github.com/dotnet/reactive/blob/fb2b69dd232bfa1415bcf09ccfd5ea2f6d4fb992/Rx.NET/Source/src/System.Reactive/Concurrency/TaskPoolScheduler.cs#L276)
If we enable the CA2213 analyzer, it finds over 600 instances. Some of them aren't problems—for example, some parts of the code retain references to `IDisposable` objects in which disposal is a) optional (e.g. because it's used to signify cancelation) and b) up to the application, not Rx. It's also possible that in some cases, the failure to dispose is benign because the relevant resource is being used in a way that doesn't actually create anything needing disposal.
We need to review each of the cases that CA2213 finds and either add suitable suppressions, or fix any genuine problems
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.