SignalR-Client-Swift
SignalR-Client-Swift copied to clipboard
Revisit threading
Currently most of the event handlers run on main queue. Consider allowing setting a queue to run events on. Note that webSockets already takes a queue and when the main queue was passed there it caused a deadlock so make sure to not regress this.
This causes a watchdog crash to occur on the app I'm working on. We are starting/closing our connection on applicationWillEnterForeground and applicationDidEnterBackground. I assume this was set up this way last year as our chat feature lives as a feature under one of our tabs in our UI, and we want customers to receive updates as they are browsing through the app. QA reported this watchdog crash to us when they repeatedly foreground/background the app that causes start/stop to occur back-to-back before connections can be established.
Is there any current recommendation for this use case to prevent this from happening? Is it legal to start/stop the connection on a background thread?
The problem here is that currently event handlers are forced run on the main queue - so for instance if you close a connection on a background thread you will get the connectionDidClose event invoked on the main thread because handlers are invoked using this method:
https://github.com/moozzyk/SignalR-Client-Swift/blob/35a30f6d589594fc91c723d977fde8573719f709/Sources/SignalRClient/Util.swift#L12-L14
We are starting/closing our connection on applicationWillEnterForeground and applicationDidEnterBackground
I think you need to do this because if not OS will stop the connection and it will not be graceful - related issue: #58
Without having more details for the crash (like stack trace) it has hard for me to speculate what the problem is. You may try commenting out the code that forces running handlers on main thread and see if it helps. The caveat is that if you modify UI in the handler which is not running on the main thread you will not see the changes. Still this should be up to the user, not framework to decide whether they want to run handlers on the main thread.
Fixed in f4558f659bead94ebac49988844cd3bc4703c8b1 and a6e8d2508fd7e81d13e7b24b8a3c1b08922f1495