+combineLatest:reduce: and -flatten: have serialization issues.

[Coneko]

Regardless of scheduler and subjects' serialization issues, methods that subscribe to multiple signals have serialization issues if the signals they subscribe to send from different threads.
+combineLatest:reduce: and -flatten: are affected for sure, +zip:reduce: doesn't seem to have issues since it synchronizes all subscriptions.

[jspahrsummers]

I'm pretty sure this is captured by #138, since if those methods send nexts/error/completed to a serialized id<RACSubscriber>, it should work even if the original signals deliver on different threads.

[Coneko]

Not if the implementation uses a different subscriber for each signal, which is what most of these methods do.

[jspahrsummers]

I'm not sure I follow. Could you create a small example?

[Coneko]

Hard to have a test case for it, but if you look at +combineLatest:reduce::

for(id<RACSignal> signal in signals) {

New RACSubscriber created for each signal

  RACDisposable *disposable = [signal subscribe:[RACSubscriber subscriberWithNext:^(id x) {

nexts are synchronized on lastValues

    @synchronized(lastValues) {
      [lastValues setObject:x ? : [RACTupleNil tupleNil] forKey:[NSString stringWithFormat:@"%p", signal]];

      if(lastValues.count == signals.count) {
        NSMutableArray *orderedValues = [NSMutableArray arrayWithCapacity:signals.count];
        for(id<RACSignal> o in signals) {
          [orderedValues addObject:[lastValues objectForKey:[NSString stringWithFormat:@"%p", o]]];
        }

        if (reduceBlock == NULL) {
          [subscriber sendNext:[RACTuple tupleWithObjectsFromArray:orderedValues]];
        } else {
          [subscriber sendNext:[RACBlockTrampoline invokeBlock:reduceBlock withArguments:orderedValues]];
        }
      }
    }
  } error:^(NSError *error) {

errors aren't synchronized

    [subscriber sendError:error];
  } completed:^{

completeds are synchronized on completedSignals

    @synchronized(completedSignals) {
      [completedSignals addObject:signal];
      if(completedSignals.count == signals.count) {
        [subscriber sendCompleted];
      }
    }
  }]];

  if(disposable != nil) {
    [disposables addObject:disposable];
  }
}

Since next, error and completed are delivered to different RACSubscribers, and are synchronized on different locks, subscriber could get deliveries from different threads concurrently.

[jspahrsummers]

I can understand why the synchronization might result in delays, but subscriber – the ultimate subscriber that each intermediate one delivers to – could still serialize the messages it receives, which would solve the thrust of this issue.

[Coneko]

Oh you're right, my bad.
Does this mean #136 is also covered by #138? It doesn't matter if a scheduler delivers concurrently if the subscriber which is the receiver of the delivery takes care of serializing the deliveries.