Repository navigation
WASI stdio (stdin, stdout) API not very useful #52614
Description
Activity
Hi! Thanks for the feature request! Could you possible provide more context?
It'd be really helpful if you could give us a comparison of the current features vs the proposed ones.
Thank you!
@nodejs/wasi
@redyetidev sure!
Currently the Node API for WASI is:
In other words when you start a WASI module, the only option for its stdin/out/err are to give real native file handles. This is quite weird and also inconvenient.
It's weird because WASI's environment is fully controlled by Node. When it writes to stdin it isn't executing native code that requires a file handle, it's calling some WASM interface function that Node provides. I presume this design is something to do with the big warning about WASI's filesystem access not being sandboxed at all at the moment. Presumably they've done the very simplest thing - just pass through WASI filesystem calls to the OS. So I think this is probably intended to be temporary anyway.
It's inconvenient because you can't interact with stdin/out/err except via a file descriptor. The only way to do this through Node is by making a file on disk which is not what you would usually want. My use case is a VSCode LSP server; stdio is used for communication.
Another option would be the
pipe()C function, but unfortunately it does not seem to be exposed by Node.The API should look more like the API for creating a child process, where you can tell it to
"pipe"the streams and then retrieve astream.Readable/Writablefor each.Hope that makes sense! The workaround I am considering is just to
fork()node, and run a module which only starts my WASI program. I thinkfork()lets youpipethe stdio streams, but I haven't actually tried it yet.Reacted by Jay PhelpsThanks! That makes more sense. I'm not on the WASI team, but the context will help them when they review this.
Thanks again for your contribution to the community!
Reacted by Tim Hutt@Timmmm you might want to check out - nodejs/uvwasi#255. I'm not sure how much preview 1 functionality wil be extended in that context so you might want to see if the preview 2 functionality provided via jco is something you want to use instead.
Reacted by Tim HuttThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Please can someone reopen this and add the never stale label? Stalebot is awful and I appreciate your attempt to make it less awful with never-stale, but it's not very useful if I don't actually have permission to reopen the issue or add that label is it?
What is the problem this feature will solve?
Currently the WASI API only lets you give file descriptors for stdin, stdout and stderr. That's not very useful. In most cases I want to interact with these streams which doesn't seem possible - at least not without a ton of platform specific work - with just file descriptors.
What is the feature you are proposing to solve the problem?
You should be able to pass
ReadableStreamandWritableStreaminstead. You can do this when spawning subprocesses.What alternatives have you considered?
Slightly ludicrously, spawning a new child process that just starts the WASI module and does nothing else seems to be the most reasonable workaround currently, though I haven't tried it.