-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Locks during Event Forwarding in RxSwift #2525
Comments
lmao |
hmm... The code doesn't compile as written. Looks like it's depending on something that hasn't been defined... I'm going to guess at the definitions but it would be better to add them to the sample. |
I do appreciate @danielt1263's wanting too help but - this is a 2 year old thread with an extremely complex and isolated example that I couldn't personally run (back then either). If the op has anything relevant to open that is reproducible, or a more general purpose use case, that would be great. I'm locking this for now, but feel free to open a brand new thread to start the discussion. Thanks! |
@isaac-weisberg I'd be happy to continue the discussion on the RxSwift slack. I think I have to solution if you are seeing this problem. |
He didn't open the original issue. |
Yea, I see that. I was thinking he was posting because he was having a problem. Maybe you are right and it was just a troll post. |
Short description of the issue:
We have identified a commonly encountered problem in RxSwift where event forwarding is performed under a lock. It leads to deadlocks and unexpected locks on threads, causing issues in code execution. We created a sample that demonstrates two specific problems with
testDeadlock
andtestTemporaryLock
methods within theRxTester
class.Expected outcome:
We assume that event forwarding should be performed outside of the locked sections. However, if there are cases that require forwarding under a lock to guarantee that only one event is forwarded simultaneously, it should use a separate lock.
What actually happens:
The issue of event forwarding under a lock has widespread implications throughout the RxSwift codebase.
Problem 1: testDeadlock
This example illustrates the deadlock caused by a specific combination of Rx operators. The major root causes:
share(replay: 1)
operator performs event forwarding under its lock for a non-first subscriber if there is an event to replay.combineLatest
operator uses theSynchronizedOnType
protocol and performs event forwarding under a lock.Problem 2: testTemporaryLock
The testTemporaryLock example showcases how a lightweight event generation (e.g., on the main thread) can unexpectedly wait on a lock due to the heavyweight processing of events in a background thread. It happens because some operators (e.g., ‘debounce’) may receive and forward events in different threads but do that under the same lock.
Presumably, similar problems might reproduce with other operators. For example, all classes using ‘SynchronizedOnType’ protocol automatically follow the pattern; some classes not using it might have similar logic (like ShareReplay1WhileConnectedConnection). At the same time, many pieces of RxSwift code perform event forwarding after locked sections, and it looks right.
Self contained code example that reproduces the issue:
Reproduction Steps:
To reproduce the issue, follow these steps:
RxTester
testTemporaryLock()
RxSwift/RxCocoa/RxBlocking/RxTest version/commit
version or commit here
Platform/Environment
How easy is to reproduce? (chances of successful reproduce after running the self contained code)
Xcode version:
Installation method:
I have multiple versions of Xcode installed: (so we can know if this is a potential cause of your issue)
Level of RxSwift knowledge: (this is so we can understand your level of knowledge and formulate the response in an appropriate manner)
The text was updated successfully, but these errors were encountered: