Define capacity semantics and backend limits for portable event loops
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 32/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- operating-systems
Direzione di ricerca
Start with std/sys/windows/event.wave at the readiness capacity handling, then compare creation, registration, and wait boundaries in the epoll, kqueue, Windows readiness, and IOCP providers. Use compiler probes at capacities 0, 1, 64, and 65, plus registrations beyond capacity, to establish current behavior. Done means the contract separates the three capacities, defines target-specific or common outcomes and clear errors, and preserves existing event behavior after the design is agreed with @LunaStev.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Motivation
The Windows readiness set enforces a fixed maximum and registration capacity, while epoll/kqueue creation uses a positive hint. The public loop capacity argument does not explain whether it is a hint or a portable registration limit.
Starting point: std/sys/windows/event.wave:45.
Validation
Audited canonical Wave 540728c2eb6cc12f5c69c3fb3fdb96e07ba059a4 (0.0.1-alpha-dev), whose tree matches the local checkout. Validation: Compared creation/add/wait boundaries in all readiness providers. Executed compiler probes use the matching checkout-built compiler and std on Linux amd64 (Rust 1.89.0 / LLVM 21.1.8). Source/header or mocked checks are not native execution on another OS.
Scope
Define creation capacity, registration capacity and per-wait output capacity separately. Preserve the bounded Windows readiness fallback and keep IOCP distinct.
Design discussion required
This issue records a proposal or an unresolved contract; it is not approval to choose new semantics. Please mention @LunaStev to discuss the design before starting implementation.
Completion criteria
- Creation at 0/1/64/65 and registration beyond capacity have documented target-specific or common results.
- Output capacity does not silently redefine registration capacity.
- Unsupported limits produce clear errors and existing event behavior remains valid.
- Lingua principale
- Rust
- Stelle
- 56
- Fork
- 21
- Merge medio
- 23h 20m
- PR unite (30g)
- 45
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di wavefnd/Wave
-
Reject unrepresentable POSIX listener descriptors before Unix-domain acceptForse già presa @ShahadatTest l’ha presa 6 giorni fa. Apertabug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
wavefnd/Wave#1082 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Preserve expression assembly result types when recording HIR conversionsForse già presa @hiyouwhatsapp l’ha presa 2 giorni fa. Apertabug help wanted
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
bug help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 53/100
I maintainer di solito rispondono entro 1 giorno
-
Preserve the previous build output when writing its Cargo receipt failsForse già presa @hiyouwhatsapp l’ha presa 2 giorni fa. Apertabug build help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 56/100
I maintainer di solito rispondono entro 1 giorno
-
Reconcile obsolete staging assets before verifying a new Nightly generationForse già presa @hiyouwhatsapp l’ha presa 2 giorni fa. Apertabug ci help wanted
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di wavefnd/Wave
Issue simili
-
Panic on live viewport resize when unstyled elements exist in display: none subtreeForse già presa @GoCoder7 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
DioxusLabs/blitz#1488 ·
I maintainer di solito rispondono entro 1 giorno
-
🏷️ good first issue enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
S-Needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
vectordotdev/vrl#2042 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno