Skip to content
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

[CODE] use user window messages rather than crossbeam channels #749

Open
raggi opened this issue Apr 13, 2024 · 0 comments
Open

[CODE] use user window messages rather than crossbeam channels #749

raggi opened this issue Apr 13, 2024 · 0 comments
Labels
enhancement New feature or request performance Something is negatively impacting perfomrance wm

Comments

@raggi
Copy link
Sponsor Collaborator

raggi commented Apr 13, 2024

We currently have separate loops that process incoming message events from windows, translate them into our own event structure, and push them to another thread via a crossbeam channel. This setup works, and there are nice aspects to this such as the richness of our own types that we'll likely want to keep.

There are some advantages though to handling events on the main event loop thread, specifically that dynamic priority boosts are sometimes applied to threads that receive events. By always deferring event processing to another thread, we're losing this, and when a system is under pressure this can lead to delayed event processing - also making some user state race conditions occur more often.

We can instead make use of the windows built in message dispatching to do more of the work that we're doing. There are places that we "send events to ourselves", and in these places instead of performing a write to a crossbeam channel, we can use the message sending functionality (https://learn.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues).

We'll want to wrap this a little for safety, to make it easy to still have our own types, but we also might consider for some of the built-in message types instead of wrapping them, we might just extend them with our own traits for convenience.

This is a larger / more invasive change that will require a good amount of testing - not a good first issue.

@raggi raggi added enhancement New feature or request performance Something is negatively impacting perfomrance wm labels Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Something is negatively impacting perfomrance wm
Projects
None yet
Development

No branches or pull requests

1 participant