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
I'm pretty sure CFRunLoopSourceSignal, CFRunLoopGetMain and CFRunLoopWakeUp are thread-safe on macOS.
std::sync::mpsc::Sender became Sync in Rust 1.72.0.
If we want to support older Rust versions, would it not be worth swapping std mpsc for crossbeam-channel in order to support sending user events from other threads?
If not a bug, then this is also a bit of an undocumented footgun. I didn't really expect EventLoopProxy to be !Sync, isn't the whole idea for sending events from other threads? Sure, I guess users can just wrap it in a Mutex, but that's introducing somewhat needlessly complicated platform-specific code downstream, and I don't think that's the intention.
The text was updated successfully, but these errors were encountered:
Nevermind, I think this is intentional, and Rust 1.72.0 caused platform differences in winit that lead to EventLoopProxy becoming auto Sync on some platforms.
I'm pretty sure
CFRunLoopSourceSignal
,CFRunLoopGetMain
andCFRunLoopWakeUp
are thread-safe on macOS.std::sync::mpsc::Sender
becameSync
in Rust 1.72.0.If we want to support older Rust versions, would it not be worth swapping std mpsc for crossbeam-channel in order to support sending user events from other threads?
If not a bug, then this is also a bit of an undocumented footgun. I didn't really expect
EventLoopProxy
to be!Sync
, isn't the whole idea for sending events from other threads? Sure, I guess users can just wrap it in a Mutex, but that's introducing somewhat needlessly complicated platform-specific code downstream, and I don't think that's the intention.The text was updated successfully, but these errors were encountered: