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

Consider Refactoring link.rs #11

Open
terhechte opened this issue Dec 18, 2021 · 0 comments
Open

Consider Refactoring link.rs #11

terhechte opened this issue Dec 18, 2021 · 0 comments

Comments

@terhechte
Copy link
Owner

The link is a bit of a terrible abstraction to handle background threads via egui. The way it works is that when an action should be performed in the background, it will send the action over a crossbeam channel to a separate thread which continuously listens for input from the channel. The thread processes the action (e.g. performs a query) and sends it back.

Egui, in the default event loop, will check for any response in the receiver crossbeam channel (e.g. 30 times per second on 30fps). If a response is available it will be applied.

There're a couple of downsides to this:

  • Request and Response are separated which makes it very difficult to use the Engine via Link in a non-async context.
  • WASM doesn't support threads, so there is a wonky abstraction to allow sync access (with way too many cfg(target_arch = wasm32)
  • This solution requires multiple additional abstractions which make it all a bit confusing to understand.

Egui apparently would work from separate threads but this might not work for other UI libraries (if we ever port it). So maybe a solution would be to have a SyncLink and AsyncLink with a closure that makes sure the request matches the response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant