dotnet / dotnet/reactive

Review undisposed resources used in async/multithreaded scenarios.

Open
#1,927 0 comments 0 reactions 0 assignees View on GitHub
[area] Rx
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.