Add EventLoopProxy::waker(self) -> Waker

[madsmtm]

As part of #3367, we're considering removing the generic on Event<T>, EventLoop<T>, EventLoopProxy<T> and the callback. By extension, we'd be getting rid of Event::UserEvent(T).

One approach to doing so would be to allow converting EventLoopProxy to the standard library's Waker type, which allows the user to wake a task (in this case the event loop) from any thread; then they can implement what they need themselves on top of that, using the standard library's mpsc::channel, mpsc::sync_channel or likewise, depending on their needs.

This is likely not a perfect solution for wakeups, we still need to properly figure out how to do timers; but this can get us some of the way there.

Blocked on #3449, we need to ensure that Sync is actually sound.

CC @notgull, I think this may be slightly useful for async?

Questions:

• Do we need a UserWoken event, or is NewEvents is enough?
• Should we hide the Waker behind a custom type like EventLoopWaker, in case we want to expose further functionality in the future?
  • We keep EventLoopProxy, and allow that to be converted to Waker.
• Is Waker too heavy-weight for this? Can we just use a function wake(&self) on EventLoopProxy? Or maybe both?
• Does the user need the ability to handle the case where the event loop has been destroyed? Or is that handled fine enough through other means, like in mpsc?

TODO:

• Finish implementation on all platforms.
• Properly test Waker implementations with updated example.
• Add an entry to CHANGELOG.md.
• Update documentation.

[dhardy]

I support this change: it makes winit simpler (at least at the API level).

Also, even though I currently use UserEvent, half the reason for that is just to create a Waker over it.

[dhardy]

I'm not sure this is wanted — eventually EventLoopProxy will (presumably) just be replaced with a Waker.

In fact, maybe just deprecate EventLoopProxy and create_proxy now, replacing with EventLoop::create_waker?

[kchibisov]

I want to reuse proxy in the future for some internal stuff in the future around Send/Sync and also, not be limited on the Waker API, since it's rather limited. But yeah, in the current state they are mostly the same.

[nicoburns]

We're doing this with custom code in Dioxus. It would definitely be nice to have in Winit.

[dhardy]

• Does the user need the ability to handle the case where the event loop has been destroyed?

No: the only purpose of waker is to awaken the event-loop. The current changes to winit (since v0.30) already force sending of user payloads through something like an mpsc channel, and this is fine in my opinion.

FYI I updated Kas to use winit last week in this PR: kas-gui/kas#583. You can also see my own Waker implementation there. So providing a waker in winit is not essential, but preferable considering how much unsafe code is required.