Treat all FDs as "nonblocking" on wasm32 #234
Comments
|
The only change in question is in |
|
Dear CLC members, let's vote on the proposal to change @mixphix @hasufell @velveteer @angerman @parsonsmatt @tomjaguarpaw +1 from me. The change fixes several tests, which were marked as fragile before. |
|
+1 |
1 similar comment
|
+1 |
|
+1 I agree with @Bodigrim's assessment here: #234 (comment) |
|
Is there some upstream discussion of |
|
+1 on this. |
|
Thanks all, that's enough votes to approve. |
On posix platforms, when performing read/write on FDs, we check the nonblocking flag first. For FDs without this flag (e.g. stdout), we call fdReady() first, which in turn calls poll() to wait for I/O to be available on that FD. This is problematic for wasm32-wasi: although select()/poll() is supported via the poll_oneoff() wasi syscall, that syscall is rather heavyweight and runtime behavior differs in different wasi implementations. The issue is even worse when targeting browsers, given there's no satisfactory way to implement async I/O as a synchronous syscall, so existing JS polyfills for wasi often give up and simply return ENOSYS. Before we have a proper I/O manager that avoids poll_oneoff() for async I/O on wasm, this patch improves the status quo a lot by merely pretending all FDs are "nonblocking". Read/write on FDs will directly invoke read()/write(), which are much more reliably handled in existing wasi implementations, especially those in browsers. Fixes #23275 and the following test cases: T7773 isEOF001 openFile009 T4808 cgrun025 Approved by CLC proposal ghc#234: haskell/core-libraries-committee#234
On posix platforms, when performing read/write on FDs, we check the nonblocking flag first. For FDs without this flag (e.g. stdout), we call fdReady() first, which in turn calls poll() to wait for I/O to be available on that FD. This is problematic for wasm32-wasi: although select()/poll() is supported via the poll_oneoff() wasi syscall, that syscall is rather heavyweight and runtime behavior differs in different wasi implementations. The issue is even worse when targeting browsers, given there's no satisfactory way to implement async I/O as a synchronous syscall, so existing JS polyfills for wasi often give up and simply return ENOSYS. Before we have a proper I/O manager that avoids poll_oneoff() for async I/O on wasm, this patch improves the status quo a lot by merely pretending all FDs are "nonblocking". Read/write on FDs will directly invoke read()/write(), which are much more reliably handled in existing wasi implementations, especially those in browsers. Fixes #23275 and the following test cases: T7773 isEOF001 openFile009 T4808 cgrun025 Approved by CLC proposal #234: haskell/core-libraries-committee#234
Hi CLC members! Based on my recent work in the ghc wasm backend, I would like to make a wasm-specific proposal. The high level tl;dr is simple: on wasm32, treat all FDs as "nonblocking" unconditionally, therefore always performing the underlying read/write operation directly while avoiding the usage of
poll()to actually wait for the FD's readiness. This makes I/O much more robust on wasm32, especially in browsers, where there's no satisfactory implementation of thepoll_oneoffwasi syscall.This has already been implemented in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11697. The patch only affects the
wasm32platform and doesn't touch any other platforms, while fixing a few test cases previously marked as fragile onwasm32. The merge request contains more detailed explanations, so I'd like to use that as the source of truth for the time being, but feel free to ask any questions or require more clarifications here :)The text was updated successfully, but these errors were encountered: