google / google/wasefire

Event handling in Rust

Open
#30 0 comments 0 reactions 0 assignees View on GitHub
crate:scheduler for:usability lang:rust needs:design
Dominant language
Rust
Stars
188
Forks
41
Avg merge
1d 5h
Merged PRs (30d)
12

Description

The current event handling doesn't compose well because all callbacks are global (any callback may run when the applet is waiting for callback). This issue proposes to instead provide 2 different mechanisms for event handling:
1. Something like `epoll` in Linux. The applet API would provide a way to wait on a specified set of events. There wouldn't be any callback. The applet would need to see which events triggered and run their associated logic. This could be done in the prelude if the high-level API is more natural with a callback.
2. Something like interrupts. The applet API would provide a way to register callbacks that would execute when a specified event triggers. This is similar to the current situation except that the callback would execute even if the applet is not waiting for callbacks. This requires the threads proposal because the callback would run concurrently. Note that a notion of priority would be useful (probably a consequence of the interrupt priority).

The first mechanism is useful when the applet wants to control when the callback (or event-related processing) executes (e.g. shared memory single-threaded operations). The second mechanism is when the callback should run as soon as possible (e.g. toggling a LED on a periodic timer).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.