Code Monkey home page Code Monkey logo

Comments (5)

RedYetiDev avatar RedYetiDev commented on June 10, 2024 1

Thanks! 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!

from node.

mhdawson avatar mhdawson commented on June 10, 2024 1

@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.

from node.

RedYetiDev avatar RedYetiDev commented on June 10, 2024

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!

from node.

benjamingr avatar benjamingr commented on June 10, 2024

@nodejs/wasi

from node.

Timmmm avatar Timmmm commented on June 10, 2024

@RedYetiDev sure!

Currently the Node API for WASI is:

image

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 a stream.Readable/Writable for 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 think fork() lets you pipe the stdio streams, but I haven't actually tried it yet.

from node.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.