How to safely shutdown observable

[mwpowellhtx]

Besides waiting for the source, timer, thread, or whatever, to stop on its own, after subscribers have been IDisposable.Dispose(). It is easy enough to dispose of the subscribers, but is that the only way to signal to the observable that it should also tear down, shutdown, whatever?

[idg10]

The answer depends on the nature of the observable. Specifically: is it hot or cold?

With a 'cold' observable, each subscription is effectively self-contains. The observable has no innate activity of its own: instead its activity is per-subscription. For example, suppose you do this:

IObservable<long> intervalTimer = Observable.Interval(TimeSpan.FromSeconds(10));

This is an observable source capable of producing events every 10 seconds. But given just the code above, it does absolutely nothing. There's no activity to shut down here, because this is a cold observable: its activity is all per-subscription.

You can see that the activity is per-subscription by subscribing twice, but at different times:

intervalTimer.Subscribe(x => Console.WriteLine($"Subscription 1: {x}, at {DateTime.Now}"));
Thread.Sleep(TimeSpan.FromSeconds(2));
intervalTimer.Subscribe(x => Console.WriteLine($"Subscription 2: {x}, at {DateTime.Now}"));

Thread.Sleep(TimeSpan.FromSeconds(40));

Running this I see the following:

Subscription 1: 0, at 29/04/2025 11:16:19
Subscription 2: 0, at 29/04/2025 11:16:21
Subscription 1: 1, at 29/04/2025 11:16:29
Subscription 2: 1, at 29/04/2025 11:16:31
Subscription 1: 2, at 29/04/2025 11:16:39
Subscription 2: 2, at 29/04/2025 11:16:41
Subscription 1: 3, at 29/04/2025 11:16:49
Subscription 2: 3, at 29/04/2025 11:16:51

This illustrates that this observable doesn't have a single series of events that all subscribers observe: the second subscriber subscribed 2 seconds after the first, and it gets its own series of events that happen 2 seconds after the first subscriber gets its events.

When the first subscriber unsubscribes, that will shut down the first stream of events. When the second subscriber unsubscribes, that will shut down the second stream of events.

So there is no single, central, shared activity that can be shut down.

It is easy enough to dispose of the subscribers, but is that the only way to signal to the observable that it should also tear down, shutdown, whatever?

The observable doesn't actually need to be told to shut down.

However, the logical model implied by your question does apply to hot observables. Those represent some source of events that exists independently of any subscription.

As far as I can remember, there are no innately hot sources in Rx. There are sources like the Interval and other timers that are inherently cold. And then there are operators—things like Select and Where, which you compose onto an existing source, and each subscription to an operator will typically cause a subscription to the underlying source. (It's more complex for some operators, but that's the basic idea.) This means that the hot/cold characteristics of the underlying source that actually feeds new events into the system will effectively be reproduced. E.g. hotSource.Select(...) will return a projection that is also hot, while coldSource.Select(...) will be cold.

You can write your own hot sources. And it will be up to you do decide how to shut those down.

[mwpowellhtx]

To clarify, I am running the observable using the new thread scheduler. Which I want for that thread to be slave, secondary, to the primary, in this case, WPF dispatcher thread. When the WPF application is shutting down, we do not want to wait for observables to be waiting for their subscriptions to shutdown, preferably cleanly, since they are running in new threads.

At present, it seems as though the observable thread shuts down, i.e. when timer driven, at the next periodic activity, which could potentially range anywhere from 30 seconds or more, depending on the timer configuration, which seems excessive.