fix -take: vs recursive -sendNext:

[kentdotn]

The following code causes infinite loop

RACSubject* subject = [RACSubject subject];
[[subject take:3] subscribeNext:^(NSNumber* value) {
    NSLog(@"value=%@", value);
    [subject sendNext:@(value.integerValue + 1)];
} completed:^{
    NSLog(@"completed");
}];
[subject sendNext:@100];

IIUC, this should output

value=100
value=101
value=102
completed

on debug console, then should stop.

[jspahrsummers]

Recursive signals are kind of an antipattern in any case, but I agree that should not deadlock.

Can you please add a unit test that fails before the fix, and passes after it?

[kentdotn]

Alright, I've done.
Though, I'm not sure where the test case should be in.
RACStreamExamples.m should be better?

[jspahrsummers]

This looks good as-is. Thanks! ✨

[jhollida24]

@jspahrsummers do you think you could elaborate a bit on why not to use recursive signals? (or point me towards something that already explains this well?)

[jspahrsummers]

@jhollida24 The primary reason is that it's hard to statically determine whether they might recurse infinitely. It's a lot easier to just avoid that problem by not recursing in a signal graph.

Secondarily, it also introduces these sorts of concurrency issues. This fixes one particular case, but there may be others (we've never done an exhaustive audit to find out).