title: What are the reference ownership semantics of ReactiveCocoa?
body: <p>When I create a signal and bring it into the scope of a function, its effective retain count is 0 per Cocoa conventions:</p>
  
  <pre><code>RACSignal *signal = [self createSignal];
  </code></pre>
  
  <p>When I subscribe to the signal, it retains the subscriber and returns a disposable which, per Cocoa conventions, also has a retain count of zero. </p>
  
  <pre><code>RACDisposable *disposable = [signal subscribeCompleted:^ {
      doSomethingPossiblyInvolving(self);
  }];
  </code></pre>
  
  <p>Most of the time, the subscriber will close over and reference <code>self</code> or its ivars or some other part of the enclosing scope. So when you subscribe to a signal, the signal has an owning reference to the subscriber and the subscriber has an owning reference to you. And the disposable you get in return has an owning reference to the signal.</p>
  
  <pre><code>disposable -&gt; signal -&gt; subscriber -&gt; calling scope
  </code></pre>
  
  <p>Suppose you hold on to that disposable so you can cancel your subscription at some point (for instance, if the signal is retrieving data from a web service and the user navigates away from the screen, canceling her intent to view the data being retrieved). </p>
  
  <pre><code>self.disposeToCancelWebRequest = disposable;
  </code></pre>
  
  <p>At this point we have a circular reference:</p>
  
  <pre><code>calling scope -&gt; disposable -&gt; signal -&gt; subscriber -&gt; calling scope
  </code></pre>
  
  <p>The responsible thing to do is to ensure that the cycle is broken when canceling a request or after  a request has completed.</p>
  
  <pre><code> [self.disposeToCancelWebRequest dispose]
   self.disposeToCancelWebRequest = nil;
  </code></pre>
  
  <p>Note that you cannot do this when <code>self</code> is being deallocated, because that will never happen due to the retain cycle! Something also seems fishy about breaking the retain cycle during a callback to the subscriber, since the signal could potentially be deallocated whilst its implementation is still on the call stack.</p>
  
  <p>I also notice that the implementation retains a process-global list of active signals (as of the time I am originally asking this question). </p>
  
  <p>How should I think about ownership when using RAC?</p>