Using wstd from another event loop on WASI 0.2, without block_on
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 30/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- rust, wasm
- Bereich
- backend, operating-systems
Rechercherichtung
Start by reproducing the panic when wstd futures are created or polled from GPUI tasks during the exported tick function, using the embedded_gpui and wasm32-wasip2 context described here. Read wstd's runtime and reactor integration alongside GPUI's executor; done would require an agreed, supported way to use http::Client, net::TcpListener, or timers without blocking block_on.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
We run GPUI (Zed's UI framework) inside a wasm32-wasip2 component, through embedded_gpui. The host drives the component by calling an exported tick function repeatedly. Each call runs GPUI's executor until it is idle and must return promptly: the plugin's UI has to keep responding, and the host enforces a time budget per call.
Plugin code, running as GPUI tasks, wants to await wstd's I/O: http::Client, net::TcpListener, timers.
Outside block_on this panics as soon as a wstd future is created or
polled:
Reactor::current must be called within a wstd runtime
block_on isn't usable here. It holds the thread until the future completes, so the UI freezes for the whole request, and the call can outlive the host's time budget. Long waits, such as an OAuth redirect listener waiting for the user to finish signing in in their browser, can't be done at all.
So there is no way to use wstd from a component whose thread belongs to another event loop. Is there a supported way to do this, or would you be open to adding one?
- Vorherrschende Sprache
- Rust
- Sterne
- 138
- Forks
- 21
- Ø Merge
- 5 T. 12 Std.
- Gemergte PRs (30 T.)
- 7
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus bytecodealliance/wstd
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
bytecodealliance/wstd#164 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 55/100
bytecodealliance/wstd#151 ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 32/100
bytecodealliance/wstd#141 · 6 Kommentare · 1 Reaktion ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
bytecodealliance/wstd#109 ·
-
Add `wstd-azure`Evtl. wieder frei @yoshuawuyts hat das vor 342 Tagen übernommen, und es ist kein Pull Request offen. Offenenhancement
bytecodealliance/wstd#104 · 1 Reaktion · 1 zugewiesene Person ·
Alle Issues in bytecodealliance/wstd
Ähnliche Issues
-
status:needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
agentic-os-org/ANOLISA#6742 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
Kc1t/alethe-agents#312 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
api: storage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
googleapis/google-cloud-rust#7153 ·
Maintainer antworten meist innerhalb von 1 Tag