🍏 iOS threading, initial work #1644
Conversation
|
@Osspial since you did the initial implementation, could you review this PR or redirect me somebody that can? |
|
@Jasper-Bekkers I wrote the macOS EL2 backend, original GCD implementation included. The iOS EL2 backend was written by my very close co-worker @mtak-, so I'm the girl you're looking for! Thanks so much for making this PR! It's fantastic to see more love being given to winit's mobile story. I'll probably find time to review this at some point this week (I've been a bit busier than usual). Always feel free to ping me for anything iOS or Android related! I'm kinda sorta supposed to keep these things nice as part of my job. I don't watch this repo for my own sanity, but I'll show up if I'm mentioned. |
francesca64
added
DS - ios
C - waiting on maintainer
|
Will do @francesca64, good to know I can ping you about this since I'll probably have more patches incoming over time as our use and experience with iOS continues. |
|
This'll need a CHANGELOG entry, since I think it's a cool improvement to announce. I hadn't noticed that the GCD usage in the macOS backend was refactored a while ago; to clarify, I wrote the raw FFI code that was there before that. I don't want it to seem like I took credit for something I didn't do! Anyway, the code quality looks good! However, when Also, I'm curious about the choice to use |
Will do.
I don't have an app like that so I have missed that during testing, I can set up a small repro to take a look at that when I get back to this next week.
|
francesca64
added
C - waiting on author
| unsafe fn screen_frame(&self) -> CGRect { | ||
| self.to_screen_space(msg_send![self.window, bounds]) | ||
| let window = self.window; | ||
| Queue::main().exec_sync(move || { |
There was a problem hiding this comment.
The way our event loop works on iOS is that we call run and process all the windowing events on another thread (we send them over an mpsc channel). However, on iOS a lot of things need to happen on the main thread as documented / asserted in winit.
It seems like this would deadlock for anyone calling these methods who is already on the main thread. Is it reasonable to say that users of this lib can't call these methods from the main thread? That is surprising to me.
A better solution for your situation might be to hoist these dispatches to your client code.
Or am I misunderstanding?
|
I've left this open for a while hoping I'd get back to it, but over the last 2 years I didn't find the time to get back to this. Closing to cleanup my open PR lists. If anyone drives by and is willing to pick this up feel free, but for me it's so low on the prio list I won't be able to get to it any time soon. When I do, I'll either re-open this or start a new PR entirely since it's probably diverged way too much. |
|
I hadn't seen this issue, but I have plans to fix this myself in #2464 in the near-ish future, so don't worry about it |
The way our event loop works on iOS is that we call
runand process all the windowing events on another thread (we send them over an mpsc channel). However, on iOS a lot of things need to happen on the main thread as documented / asserted in winit.This follows along with some of the macOS code and uses Grand Central Dispatch to move the execution of some of these code blocks back to the main thread.
This doesn't remove all the asserts, nor does it fix all the cases, however I've moved over enough for our internal use-case.