New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrent RACSchedulers can result in delivery race conditions #136
Comments
|
I think the lesson of this and #94 is that |
This also implies calling I've always used RAC very conservative thread-wise, so I haven't looked into it much, but it seems to me the documentation doesn't make it very clear what is and what is not thread-safe. |
@Coneko That's a good point, but we can solve it by serializing I definitely don't think |
I want to say that this can be closed once #138 is implemented, but I'm worried there's something I'm overlooking. I'll think about it a bit more. |
Based on how I've fixed For example: RACSubject *subject = [RACSubject subject];
[RACScheduler.backgroundScheduler schedule:^{
[subject sendNext:@0];
}];
[RACScheduler.backgroundScheduler schedule:^{
[subject sendNext:@1];
}];
[RACScheduler.backgroundScheduler schedule:^{
[subject sendNext:@2];
}]; Would you expect 0, 1, and 2 to arrive in that order? There's no guarantee that's how it'll happen right now, because each scheduled block is asynchronous on a concurrent queue, and context switching could cause a later send to complete before an earlier one. Now, whether this is actually an issue in practice, I still don't know. |
It makes sense to document this behavior in |
👍 Fair point. |
As part of this, it'd also be nice to add a couple things to // Whether this scheduler is concurrent.
@property (nonatomic, readonly, getter = isConcurrent) BOOL concurrent;
// Returns a serial RACScheduler that schedules its blocks on the receiver.
- (instancetype)asSerialScheduler; |
If two nexts, or a next and a completed, etc., get sent to a concurrent GCD or operation queue, they might be processed simultaneously. Most
<RACSignal>
and<RACStream>
methods are not written to accommodate this.<RACScheduler>
should serialize scheduled blocks, even when ultimately delivering to a concurrent queue. The deferredScheduler is also extremely dangerous, because it seems like we can't make the same guarantees there.The text was updated successfully, but these errors were encountered: