Question regarding memory/resource management

[reactivecocoa]

Question regarding memory/resource management

[andersio]

That is just one tidbit of the implementation, if you mean SignalState retaining the Signal. It would still be released when it gets a termination event.

[cloutiertyler]

Specifically I am confused about is this. Each signal maintains a reference to itself via its SignalState if there is at least one observer added to the signal. So basically if I had a function like:

func f() {
    let (signal, observer) = Signal<String, NoError>.pipe()
    signal.observeNext { next in print(next) }

    observer.sendNext("a")
}

f()

wouldn't I be leaking signal after calling f, since it has a reference to its itself?

[cloutiertyler]

Could you point me to where the Signal is released when a terminating event is sent through? It would have to break this retain cycle, right?

[andersio]

We swap out, dispose of the generator disposable and throw away the SignalState when a termination event is received.

https://github.com/ReactiveCocoa/ReactiveSwift/blob/master/Sources/Signal.swift#L80

[cloutiertyler]

Ah I see, that's a neat trick. I would still have the leak in the above example though since no interrupt, nor other terminating signal, was sent, correct?

[andersio]

Yes, unless you detach the observer.

This actually falls into the caveat of this design: ReactiveCocoa/ReactiveCocoa#2959 (comment).

[andersio]

In general, Signals should be terminated.

Even in the case where they don't, they are usually a derived "view" from something that's really permanent, and can be disposed of when no observers remain, e.g. NotificationCenter.default and a signal of Notification derived from it.

[cloutiertyler]

Oh, awesome, thanks for the link! That's very helpful. I'm not sure there is any other way to do it really. I have been playing around with making this to get a better understanding of FRP and ReactiveCocoa and to play around with different possible APIs. I ended up with basically the same solution although it looks slightly different and mine will definitely leak if there is no terminating event even if there are no observers on the signal. You can see what I did here.

[cloutiertyler]

Actually I lied, it's not quite the same. In the case above, with my implementation the Signal would be properly deallocated since I don't care whether or not there are any observers on the Signal. Since no one holds a reference to input observer after f(), and the input observer holds the only strong reference to the Signal, there is no cycle and the Signal will be dealloc'd. Not sure of the full ramifications of a design like this are, but in this specific case something like it wouldn't leak.

[andersio]

I won't comment on any other implementations. But I'd suggest you modelling the expected behavior in different circumstances as test cases. That would definitely help the iterative process, and it was how ReactiveSwift ended up with the current implementation.