It is a foot-gun that `EventLoopProxy` is `!Sync` on macOS

[gretchenfrage]

Hi all, thank you for your consideration. Someone previously created #3220 on this subject, but then closed their own issue when they found that there actually is an obstacle to making EventLoopProxy Sync on macOS. However, I'm creating this issue for further discussion because I think it is unfortunate that the API is as such.

EventLoopProxy being Sync only on non-macOS platforms makes it so that one can write code with winit that doesn't seem to be using any platform-specific features but nonetheless fails to compile on macOS while compiling fine on other platforms, which I think goes against winit's generally very nice goals and behaviors in terms of cross-platform abstraction.

Some possible ways I can imagine dealing with this include:

• Make EventLoopProxy always !Sync
• Make EventLoopProxy Sync on macOS by wrapping its internals in a mutex
• Make EventLoopProxy always !Sync, but create a platform-specific SyncEventLoopProxy type which is like EventLoopProxy but Sync, and which EventLoopProxy can be converted into through a platform specific-API
• Create a non-default feature flag which makes EventLoopProxy Sync and document that that feature flag can only be enabled on certain platforms

[madsmtm]

I mean, EventLoopProxy is Clone, so you can always just clone it just before sharing it with another thread.

That said, the underlying CFRunLoopSourceRef is considered being marked Send + Sync in servo/core-foundation-rs#649, and I'm pretty sure that's correct, the CFRunLoopSourceRef is immutable, so should be safe for us to just add an unsafe impl<T: Send> impl Sync for EventLoopProxy {}`, at least on macOS.

[madsmtm]

Seems like this will need some work on the web too, @daxpedda?

[gretchenfrage]

Yeah, it is pretty easy to fix a program that fails to compile on macOS for this reason on the user side--I just like the idea that if a winit program compiles on a supported platform and doesn't noticeably use any platform-specific features it should compile on all supported platforms.

By the way, I really appreciate the keyboard input handling rework you all recently pushed through. The fact that it associates the physical/logical and textual input interpretations of a single key press to a single event helped me easily solve a bug of mine that I had previously been using a super hacky work-around for (relating to pressing the T button to open a text input, and not wanting that same T button press to also cause a T character to be typed in after opening it).