-
Notifications
You must be signed in to change notification settings - Fork 892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
event_loop: remove generic user event #3694
Conversation
5244f86
to
d5fdf2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the macOS, iOS and Windows implementations now to the best of my ability.
@@ -2454,7 +2392,7 @@ unsafe extern "system" fn thread_event_target_callback( | |||
// user event is still in the mpsc channel and will be pulled | |||
// once the placeholder event is delivered to the wrapper | |||
// `event_handler` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Update comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's relatively accurate given that we still do roundtrips with channel, because I'm afraid to change that to use something else, because I can not really test this one.
pub fn send_event(&self, event: T) -> Result<(), EventLoopClosed<T>> { | ||
self.sender.send(event).map_err(|mpsc::SendError(x)| EventLoopClosed(x))?; | ||
pub fn wake_up(&self) { | ||
self.user_wake_up.store(true, AtomicOrdering::Relaxed); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is a correct ordering to use here, technically the CPU could choose to execute all the code below, and wake up the main thread to process the event, before actually setting this flag (SeqCst
is not strong enough to do this either, as it'd have to have been used in CFRunLoopWakeUp
as well, which I'm not sure it has).
The proper way to do this would be to emit the wake-up event (or just set a flag) inside the event_loop_proxy_handler
function above (which runs on the main thread). That's a bit of a larger rework though, the current impl will work fine for now (and the old code had the same problem), I'll change it myself at a later point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing I care about is that the event is emitted only once and the wake up is not lost. Though, I think more intense sync should be on the user here...
b3386f4
to
11bf122
Compare
Web should be good now. Apart from us agreeing on the details and adding some documentation I'm very much in favor of moving forward with this. |
4e8bbc1
to
4ac84e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK to X11
ac357ed
to
aa5b67b
Compare
aa5b67b
to
b142035
Compare
b142035
to
0725b2e
Compare
I'm not entirely sure whether I've updated macOS/ios correctly after recent changes. |
0725b2e
to
3f8d9b3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really would've preferred the backend-specific changes to move away from Event
to have happened in separate PRs, it makes it a bit difficult to review all the changes. But done is done, so oh well.
macOS and iOS impls look good after comments. I still feel we need to document things better as discussed in #3694 (comment) before this is ready, but that's probably about it.
3f8d9b3
to
e99f7b5
Compare
Web needs re-review because I'm not sure if the rebase was done correctly, probably not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Web needs re-review because I'm not sure if the rebase was done correctly, probably not.
Nope, its fine!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've submitted #3753 to reduce the macOS diff in this PR, and I believe that the iOS diff could be reduced by not renaming Event::WindowEvent
and Event::DeviceEvent
(as suggested below).
I'll try to document things as I think they should be documented to resolve #3694 (comment), for convenience I'll just push it directly to this PR in a few minutes, feel free to edit the commits.
Also, you don't have to rebase for my sake, a merge commit is fine in a PR IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In light of madsmtm's proposed changes.
@madsmtm have you extracted your diff out of my commit or what exactly was done? If it's something new I'd let you handle that instead. |
Let the users wake up the event loop and then they could poll their user sources.
Revert the internal rename to not bloat the diff a lot. However clippy should be silenced on the given enum variants now, because the Event is private.
0abf477
to
ea6388d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@madsmtm have you extracted your diff out of my commit or what exactly was done? If it's something new I'd let you handle that instead.
You mean in #3753? Mostly, yeah (with a bit of renaming to my taste). The intention is that in this PR, you remove the MapUserEvent
helper. I can do it if you want me to? Nvmd, I did it, feel free to rebase.
Have submitted my suggested documentation, @notgull @daxpedda @kchibisov please review that too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please let me know if I'm way off here!
Co-authored-by: daxpedda <daxpedda@gmail.com>
Co-authored-by: daxpedda <daxpedda@gmail.com>
Co-authored-by: daxpedda <daxpedda@gmail.com>
b73ea9d
to
5af055a
Compare
Co-authored-by: daxpedda <daxpedda@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @madsmtm for improving the documentation around this!
Let the users wake up the event loop and then they could poll their
user sources.
--
I haven't tested these changes outside of Wayland. Please carefully review your backend changes.
I know that
Windows
andWeb
are likely done not correctly.On macOS/ios the atomic ordering is likely not correct either, but I'm not familiar enough with the CFRunLoop behavior to ensure that.
There's also #3424 , but the proxy should be platform specific and in the end just a trait. Maybe we'll use
Waker
, but for now I went with just removing generic which prevents me from usingdyn
more actively.This PR is build on top of #3683