-
Notifications
You must be signed in to change notification settings - Fork 338
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
Integration Tests
: add MainThreadMonitor
to ensure main thread is not blocked
#2463
Conversation
let deadline = DispatchTime.now() + Self.threshold | ||
let result = semaphore.wait(timeout: deadline) | ||
|
||
precondition( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't make this a XCTFail
because it wouldn't be reported if the main thread is completely blocked.
2e64d23
to
f779252
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea!
@@ -34,6 +34,8 @@ class BaseBackendIntegrationTests: XCTestCase { | |||
// swiftlint:disable:next weak_delegate | |||
private(set) var purchasesDelegate: TestPurchaseDelegate! | |||
|
|||
private var mainThreadMonitor: MainThreadMonitor! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a cool idea. Any thoughts on using this in other integration tests (not only backend integration tests)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the base class for all integration tests.
f779252
to
aee4f96
Compare
See #2463. If you're actively debugging and interrupt the main thread, it'll end up asserting, which isn't very convenient. Copied the logic from https://stackoverflow.com/a/33177600/401024. It's not the safest code, but this only runs in tests.
) See #2463. If you're actively debugging and interrupt the main thread, it'll end up asserting, which isn't very convenient. Copied the logic from https://stackoverflow.com/a/33177600/401024. It's not the safest code, but this only runs in tests.
… not blocked (#2463) We've had a few reports of deadlocks (#2412, #2375). This might have not detected them, but it would detect future issues, as well as busy operations running on the main thread. Example: 
) See #2463. If you're actively debugging and interrupt the main thread, it'll end up asserting, which isn't very convenient. Copied the logic from https://stackoverflow.com/a/33177600/401024. It's not the safest code, but this only runs in tests.
This was introduced in #2463, as a way to verify the SDK didn't have any deadlocks (#2412, #2375). However, it has caused more trouble than it's worth, because that loop keeps the main thread busy. This solution proposed by @aboedo makes it only check every 3 seconds. If there is a deadlock, it would still detect it. But after it's verified there is no deadlock, it won't check again until that interval has elapsed again. This makes it so that on a test that takes 6 seconds to run, we only execute this code 2 times instead of... a lot.
We've had a few reports of deadlocks (#2412, #2375). This might have not detected them, but it would detect future issues, as well as busy operations running on the main thread.
Example:
