You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I were to guess, the calls you're making in Fetch end up doing syscalls on iOS that the Go runtime needs to block the thread. If you end up on the UI thread (usually the main thread, which I suppose might be where you're calling into Go from Swift) then you'll see UI stalls. This doesn't fully explain why time.Sleep works though, since once you call into Go, the goroutine created for the thread calling into Go is bound to that thread. That being said, time.Sleep does not in general block a thread, and the goroutine just ends up in some timer data structures, to be executed later.
Do you have more details on how Go is being called from Swift? I'm not personally familiar with x/mobile, so I don't know what exactly the intermediate code is doing. I assume the call is going through cgo, but other than that, it would be good to have more details from someone familiar.
changed the title
x/mobile: Asynchronous bug occurs when the method that communicates with the server in qui-go is an IOS library.
x/mobile: UI hangs when Go code called from Swift communicates over the network; time.Sleep works fine
Jan 30, 2024