The events are a scheduling mechanism, not the work done. Performance probably relates more to the ratio of time spent selecting the next event to time spent e

The events are a scheduling mechanism, not the work done. Performance probably relates more to the ratio of time spent selecting the next event to time spent executing code between yields than anything else: a thread waiting on an event joins a queue, a thread requesting an event joins the same queue but also flags it as ready, and a thread blocking an event flags the queue as not ready. When a queue is selected, it's drained completely before a new queue is selected. The run cost of the scheduler would depend mostly on the structure used to maintain the ready set, but a basic double ended linked list would provide linear time operations for ready/blocked management. Whole program compilation could provide lookups or perfect hashes for event queueing, or partial compilation could rely on imperfect hashing. Optimising during compilation might work best by trying to fuse events such that the scheduler is invoked less often. Things that are not apparent from a lightweight article like this include state transfer (how do I know details of the card inserted?) and the likelihood that I'd keep the code to each b-thread and hack on those to make new ones...