Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

perf(sidecar): event-driven pump to remove residual sync-RPC timer latency

Aperta
  • Qualcosa non va?
#80 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
backend, performance

Direzione di ricerca

Inizia da crates/sidecar/src/stdio.rs e segui run_async, pump_process_events, process_event_receiver e il canale degli eventi di esecuzione. Verifica che gli eventi di processo accodati risveglino il ciclo select senza latenza del timer per chiamata né tick di inattività, mantenendo disponibile il fallback grossolano.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Background

Guest sync fs/module RPCs are serviced by pump_process_events, which the stdio
select loop (crates/sidecar/src/stdio.rs) only runs on the EVENT_PUMP_INTERVAL
timer. PR #77 reduced that interval from 5 ms to 250 µs, which cut per-call
latency dramatically (stat 7.5s→1.3s, read 7.6s→1.2s over 1500 ops). But it is
still a polling timer: a blocked guest call waits up to one interval before the
host dequeues it, and the loop wakes on every tick even when nothing is pending.

Proposal

Make the pump event-driven: wake the stdio select loop the instant the
execution layer enqueues a process event (e.g. a JavascriptSyncRpcRequest),
instead of relying on the timer. Concretely, plumb a notify signal from the
execution event channel up into the run_async select loop (an extra select!
arm that awaits "a process event is ready"), and keep a coarse timer only as a
fallback. This removes the residual ~250 µs/call timer latency and the idle-tick
cost entirely.

Notes / constraints

  • An adaptive fine/coarse interval was tried in PR #77 and was unstable
    (oscillation/livelock under load) because it recreated tokio::time::interval
    mid-select. A true notify channel avoids that.
  • pump_process_events already returns whether it did work; the receiver
    (process_event_receiver) is currently drained via try_recv inside the pump,
    so an event-driven design must coordinate a single consumer.

Expected impact

Removes the remaining timer latency on every guest sync fs/module RPC; biggest
remaining win for fs-heavy guests after PR #77.

Lingua principale
TypeScript
Stelle
1k
Fork
54
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rivet-dev/dynamic-apps

Tutte le issue di rivet-dev/dynamic-apps

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.