Replies: 1 comment 1 reply
-
Probably not. Part of libuv's design philosophy is that it's a complete package. Documented APIs should be there, unconditionally. What would be acceptable is adding a wasm.c backend that stubs out impossible-to-implement functionality (e.g. by returning UV_ENOSYS), although I kind of wonder what's left at that point.... timers, check/prepare/idle handles, maybe the thread pool, anything else? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm using libuv in actonlang/acton, a programming language, where libuv is used by the run time system for handling I/O as well as running the core processing loop that runs language continuations. Acton programs compile to binary executables on common platforms like Linux and Macos. I'd like to be able to target WASM. Now WASM doesn't have IO the way we are used to from normal POSIX style OSes but I still want to use libuv for my internal scheduling, timers etc so don't want to rip out libuv completely. In order to support this, I'd like to condition large (majority!?) part of libuv on some flag so I can get it to compile for WASM and potentially other similar targets (freestanding!?). Does there currently exist a way to do this?
Would a patch for something like this, i.e. adding preprocessor conditions, be acceptable?
libxev, which is rather similar to libuv, does support targetting wasm and so I assume it has conditionals like this somewhere internally.
Beta Was this translation helpful? Give feedback.
All reactions