3 ms·

That depends entirely on the runtime, and its WASI implementation. wazero [1], which I'm most familiar with, allows you to decide in a relatively fine-grained

That depends entirely on the runtime, and its WASI implementation. wazero [1], which I'm most familiar with, allows you to decide in a relatively fine-grained way what capabilities your WASI module will have: command line arguments, environment variables, stdin/out/err, monotonic/wall clock, sleeping, even yielding CPU… Maybe more importantly, filesystem access can be fully emulated, or sandboxed to a specific folder, or have some directories mounted read-only, etc; it's very much up to you. I've used it to wrap command line utilities, and package them as Go libraries. For one example, dcraw [2]. WASM makes this memory safe, and I can sandbox it to access only the single file I want it to process (which can be a memory buffer, or something in blob storage, if I want it to). Notice in [3] how you provide an io.ReadSeeker which could be anything from a file, a buffer in memory, or an HTTP resource. The spaghetti C that dcraw is made of won't be able to access any other file, bring your server down, etc. 1: https://wazero.io/ https://wazero.io/ 2: https://dechifro.org/dcraw/ https://dechifro.org/dcraw/ 3: https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw

emmanueloga_ 3y ago
Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing! -- 1: https://github.com/tetratelabs/wazero/blob/main/examples/basic/add.go#L45C38-L45C38 https://github.com/tetratelabs/wazero/blob/main/examples/bas... 2: https://natsbyexample.com/examples/messaging/pub-sub/go https://natsbyexample.com/examples/messaging/pub-sub/go
- ncruces 3y ago
  Yes: if so configured, wazero respects context cancelation (including, but not limited to, timeouts). This has a slight toll on performance: a call back from WASM AOT-compiled-assembly into Go is introduced regularly (on every backwards jump?) to give the Go runtime the opportunity to yield the goroutine and update the context (and break infinite loops), even when GOMAXPROCS=1. Coordinating with the Go scheduler might be an area where there's some room for improvement, if fact.

emmanueloga_ 3y ago

Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing! -- 1: https://github.com/tetratelabs/wazero/blob/main/examples/basic/add.go#L45C38-L45C38 https://github.com/tetratelabs/wazero/blob/main/examples/bas... 2: https://natsbyexample.com/examples/messaging/pub-sub/go https://natsbyexample.com/examples/messaging/pub-sub/go

ncruces 3y ago
Yes: if so configured, wazero respects context cancelation (including, but not limited to, timeouts). This has a slight toll on performance: a call back from WASM AOT-compiled-assembly into Go is introduced regularly (on every backwards jump?) to give the Go runtime the opportunity to yield the goroutine and update the context (and break infinite loops), even when GOMAXPROCS=1. Coordinating with the Go scheduler might be an area where there's some room for improvement, if fact.