winit icon indicating copy to clipboard operation
winit copied to clipboard

Make `Window` `!Send + !Sync`

Open madsmtm opened this issue 2 years ago • 2 comments

Part of https://github.com/rust-windowing/winit/issues/3367, opening to discuss separately.

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)?

Related: https://github.com/rust-windowing/winit/issues/3317, https://github.com/rust-windowing/winit/issues/3434.

madsmtm avatar Jan 27 '24 03:01 madsmtm

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.

daxpedda avatar Jan 27 '24 09:01 daxpedda

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.

kchibisov avatar Jan 27 '24 12:01 kchibisov