-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Open
Labels
acceptedThis proposal is planned.This proposal is planned.proposalThis issue suggests modifications. If it also has the "accepted" label then it is planned.This issue suggests modifications. If it also has the "accepted" label then it is planned.standard libraryThis issue involves writing Zig code for the standard library.This issue involves writing Zig code for the standard library.
Milestone
Description
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.
ifreund, czrptr, phan-do, matu3ba, Hadron67 and 43 moreHe-Pin, chiumichael and corpix
Metadata
Metadata
Assignees
Labels
acceptedThis proposal is planned.This proposal is planned.proposalThis issue suggests modifications. If it also has the "accepted" label then it is planned.This issue suggests modifications. If it also has the "accepted" label then it is planned.standard libraryThis issue involves writing Zig code for the standard library.This issue involves writing Zig code for the standard library.