komorebi icon indicating copy to clipboard operation
komorebi copied to clipboard

[CODE] use user window messages rather than crossbeam channels

Open raggi opened this issue 1 year ago • 0 comments

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 avatar Apr 13 '24 20:04 raggi