EventUnsubscriber "wasting" a thread? about observablecomputations

[IgorBuchelnikov]

First, a little history. In earlier versions of ObservableComputations 2.x, events were unsubscribed on the same thread as the computation. During load testing, it turned out that unsubscribing from events greatly reduces overall performance. Therefore, I made a mechanism for unsubscribing from events in a dedicated thread ("ObservableComputations events unsubscriber #0").
In general, it is required to ensure performance with frequent single unsubscribes (one event, one source, one subscriber). Of course, I could take a thread from the thread pool for each unsubscribe. But at peak loads, this can lead to a short-term exhaustion of the thread pool, which can lead to loss of responsiveness to input or output (lag). Creating a new thread to unsubscribe (without using a pool) is an even worse solution, since creating a thread is an expensive operation. A use case of the thread pool is the asynchronous execution of heterogeneous tasks, the parallel execution of which ensures that the application is responsive to input or output. In the case of unsubscribing from events, the task is one - unsubscribing from events, parallel execution of several unsubscribes will not give any advantages, and therefore we can save the pool of threads for its intended use.
The TaskCompletionSource you suggested is an abstraction over Task, which is an abstraction over the thread pool and threads. AsyncManualResetEvent is an abstraction over TaskCompletionSource.
A sleeping (idle) thread consumes few resources. ManualResetEventSlim is a low-level primitive and therefore gives good performance.
If 1 events unsubscriber thread can't cope, you can increase the number of such threads (OcConfiguration.EventUnsubscriberThreadsCount).

[dbruning]

Thanks for taking the time to explain in such detail! Makes a lot of sense.
In my particular use case, I know that I'm not unsubscribing often (or actually using ObservableComputations very heavily at all), so the separate thread is not of benefit to me and just adds "noise" to my performance-profiling session. I need to exclude this thread, because although it's not consuming resources, my sampling peformance profiler shows that the thread has an active stack trace.
It's not a major problem at all; I can just exclude that thread. But if there was a way that the library could only spin up the separate thread when it's needed (maybe after a threshold of unsubscribes per second?) that would be cool. Or, provide a way I can choose to switch off that thread and just to the unsubscribes in the same thread as the computation. I'm sure that's a low-priority request though!

Thanks for your work on this library.