Skip to content
Snippets Groups Projects
Forked from Glasgow Haskell Compiler / GHC
Source project has a limited visibility.
  • Cheng Shao's avatar
    2eca52b4
    base: treat all FDs as "nonblocking" on wasm · 2eca52b4
    Cheng Shao authored
    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:
    https://github.com/haskell/core-libraries-committee/issues/234
    2eca52b4
    History
    base: treat all FDs as "nonblocking" on wasm
    Cheng Shao authored
    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:
    https://github.com/haskell/core-libraries-committee/issues/234
Code owners
Assign users and groups as approvers for specific file changes. Learn more.