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
We've worked hard on trying to make Window safely Send + Sync, but this somewhat obscures what's really happening underneath the hood: Some backends use Mutex, others like macOS/iOS dispatch the events to the main thread (and you may even deadlock if you try to use the window from a thread while the event loop is not running).
So maybe this is actually the wrong solution, and windows should not actually be Send + Sync? Though if we remove it, we'll still have to find some way of allowing users to render on different threads.
Are there other use-cases for Send + Sync windows (other than rendering)?
Are there other use-cases for Send + Sync windows (other than rendering)?
It is still highly desirable for MT applications to be able to call all sort of Window methods in different threads.
The go-to suggestions to solve this is a WindowHandle::queue() method that basically works like the abstraction used in iOS/MacOS/Web right now: just package a closure that will be executed on the event loop.
Backends that do support certain methods to be called in any thread will have to do that via extension.
I think we should just have a WindowHandle implementing Window more or less generically with the help of the queue, however certain backends may overwrite methods they can dispatch straight away. It's a bit more work, but no need to separate functionality, etc.
Part of #3367, opening to discuss separately.
We've worked hard on trying to make
Window
safelySend + Sync
, but this somewhat obscures what's really happening underneath the hood: Some backends useMutex
, others like macOS/iOS dispatch the events to the main thread (and you may even deadlock if you try to use the window from a thread while the event loop is not running).So maybe this is actually the wrong solution, and windows should not actually be
Send + Sync
? Though if we remove it, we'll still have to find some way of allowing users to render on different threads.Are there other use-cases for
Send + Sync
windows (other than rendering)?Related: #3317, #3434.
The text was updated successfully, but these errors were encountered: