Proposal: Event loop redesign

[kprotty]

The current event loop is not ready yet (relatively slow, windows unfinished, bugs/races) and many wish for it to be. From the discord communities at least, there seems to be enough interest to warrant addressing this, with some interested in helping out. My question then is: what do people really want out of the standard libraries event loop? Toying with some designs locally produced incomplete implementations from lack of a direction. In addition to what people want from an event loop, how do they also want it implemented? Here are some example properties:

• Multi-threaded by default?
  • Threading is customizable (NUMA, affinities, priorities)?
  • Work-stealing or work-requesting scheduler? configurable?
• Globally configured?
  • Other standard library stuff subscribing to the event loop automatically/case-by-case?
  • Multiple event loops in the same program?
• Performance goals?
  • Prioritize simple implementation over absolute efficiency?
  • What sort of sacrifices should be made here to accommodate other metrics?
  • Is there a definite goal it should strive to maintain (e.g. faster than X in Y)?
• What features should it provide API wise and how would those look like?
  • Ability to lock execution to a specific OS thread?
  • Influence scheduling (hard/soft priorities, QoS classes, fairness)?
  • Scheduling patterns (batch, switchto, scheduling cancellation)?
• What should sync primitives (i.e. Mutex, Channel) and event sources (i.e. I/O, timers) look like?
  • Support cancellation?
  • Are allowed to dynamically allocate (i.e. heap alloc) internally?
  • Require user-provided, intrusive memory to operate?
• How async should it be?
  • Usable as a C api?
  • Usable without zig features (i.e. comptime, threadlocal, async) for easier bootstrap?
• Should we even have an event loop at all?
  • Only provide thread pool / io-poller / timer datastructures separately?
  • GCD/libdispatch approach? (user creates distinct/specific work-queues and pushes work into them per app)
  • Global thread-pool/executor approach? (think windows ThreadPool or windows UMS)

I'm open to adding more considerations if others have some. Just want to understand the requirements before making any sort of PR.

[kprotty]

@ethindp Zig async is a language feature while the event loop is a library component which uses it. This means an event loop is not required for use in other environments like WASM/embedded as you've noted. Event loop just refers to the abstraction which starts and schedules coroutines (async frames). As for "too complicated", that's too subjective of a criteria; It would be more helpful to list which areas or things you were trying to (or would like to) do that felt confusing instead.

Regarding Rust, the "yield points" are explicit awaits. You also can't "wake up" a Task there. You instead implement generators (called Futures) which take in things called Wakers as a way for you to tell the executor/caller when to poll them again. Learning about async rust (as opposed to relating it to Zig) is probably out of scope for this issue.

I'd disagree regarding not focusing on efficiency early: Event loops aren't something you can "optimize later" as they are limited by your designs. For instance, you can't optimize a select-based API to use io_uring/IOCP efficiently. Nor could you make something like libuv or libdispatch without internal heap allocation.

I agree that people will write their own, but I think its better to at least make doing so easier by providing high performance smaller components like an IO queue, thread pool, timer queue, etc.

[He-Pin]

It's worth to take a look at cats-effect 's design too.

[aep]

This type of zero-copy IO model is common in HPC environments and uses DPDK/efvi/vma/XDP etc.

poking around DPDK right now and super anxious about using zig, because of the possibility that some day it will just start having an opinion about IO and then you end up with both things next to each other and having to sync them, like they do with rust now.