RX Switch（）的订阅和取消订阅订单

Question

So I have written a rough draft of the problem I'm encountering. I have an IObserverable< IObservable< TResult>> which contains my stream, and I would like to use switch to get the latest items from it, however the problem I have can be neatly demonstrated with the code below:

        var obs = Observable.Create<IObservable<int>>(sub =>
        {
            var item = Observable.Create<int>(innersub =>
            {
                var count = 0;
                return Observable.Interval(TimeSpan.FromSeconds(2)).Subscribe(x => innersub.OnNext(count++));
            }).Publish().RefCount();

            return Observable.Interval(TimeSpan.FromSeconds(10)).Subscribe(x => sub.OnNext(item));
        });

        obs.Switch().Subscribe(x => Console.WriteLine(x));

The above test case shows that when used in conjunction with Publish().RefCount() the switch first unsubscribes and then subscribes to the new item.

What I would like is for a continuous stream of numbers going up, however the test shows the "item" is disposed of first before the new subscription hits and I lose that count and have to start again.

If the item is the same, and refcount is used, what I would like is for the subscription to happen first, so refcount is happy, and then the old subscription disposed of. Is this behavior that RX can demonstrate by default or would it require some bodging to get right? I'm confident I could write a simple enough extension method based on a cut down version of the RX source code but if it already exists or there is a better way I'd like to know first.

Edit: The code written was a naive example to demonstrate the problem in a simple way. What I actually have is an observable that publishes a new observable regularly, which has different filters on it, but which ultimately boils down to the same publish/refcount observable at the base of it all. (The where clause changes, or the select does something different. The real use is a .Merge() of several streams so I'm confident in my logic and my conclusion of the problem). I'm well aware that my example could be simplified.

Answer 1

You're going to have to look at the source as the previous observable gets disposed before the current one gets subscribed to. That's how .Switch() works.

If Rx disposed after the new subscription, the intent of your code appears to be the equivalent of simply doing this:

var obs = Observable.Create<int>(innersub =>
{
    var count = 0;
    return Observable.Interval(TimeSpan.FromSeconds(2))
        .Subscribe(x => innersub.OnNext(count++));
});

obs.Subscribe(x => Console.WriteLine(x));

And in this example it then boils down to:

var obs = Observable.Interval(TimeSpan.FromSeconds(2));

obs.Subscribe(x => Console.WriteLine(x));

Perhaps you could let us know what your underlying requirement is and we could work on that?

Answer 2

This operator is designed primarily for cold observables. Switch unsubscribes from the previous observable before subscribing to the new one. Otherwise there would exist a race condition where extra events might slip through during the brief period it was subscribed to both.

Since your underlying observable is hot, you might consider an alternative solution where you just modify the filter/select "on the fly" instead of using Switch to "re-subscribe". Something like:

source
    .Where(t => ApplyCurrentFilter(t))
    .Select(t => ApplyCurrentProjection(t))
    .Subscribe(...);

// do something that changes what `ApplyCurrentFilter` does...

I don't know if this is better or worse than your current solution, but it does avoid the need to unsubscribe/resubscribe from source data.

Answer 3

As has been said, Observable.Create produces a cold Observable, and Publish.RefCount only makes it hot while there are still subscribers there. It would be possible to write your own version of Switch that subscribed the new subscriber before disposing the old. But I'd be very wary of race conditions. And in general, it feels a bit of a weird thing to do, which in Rx usually signals there's another way to do what you want that's cleaner.

In this example, if you have the desired result, there's no purpose to publishing many Observables and Switching them because really you just want to be subscribed to one observable for the full duration. Hence how it boils down to what Enigmativity says.

However, obviously it's a contrived example so let's assume there's a more complicated situation that requires this approach - it may help if you're able to elaborate. From the example, it seems you only want to subscribe to the inner observable once, ever. Based on that requirement, RefCount is not appropriate, but I assume you're using it because you want a shared observable at the core, which you're wrapping with other operators that you want to act differently each time. If that's the case, you could possibly use an approach like this:

var obs = Observable.Create<IObservable<int>>(sub =>
{
   var item = Observable.Create<int>(innersub =>
   {
       var count = 0;
       return Observable.Interval(TimeSpan.FromSeconds(2))
                        .Subscribe(x => innersub.OnNext(count++));
   }).Publish();

   bool connected = false;
   var disposables = new CompositeDisposable();
   disposables.Add(Observable.Interval(TimeSpan.FromSeconds(10))
                             .Subscribe(x =>
                             {
                                 // push the new stream to the observer first
                                 sub.OnNext(item);

                                 if (!connected)
                                 {
                                     connected = true;
                                     disposables.Add(item.Connect());
                                 }
                             }));

   return disposables;
});

I haven't thought through potential race conditions with this approach, etc, and a lot depends on your real situation. However, in the basic test from the original post, this seems to behave how you want it to.