Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't really get it either. It's kind of missing which interfaces are actually provided to the WASM script, and how the magic webserver that is described in the docs is working.

Most WASI implementation so far seem to just make a stdin and stdout available for a WASM program - which wouldn't really be enough to run a webserver in it.

Is this example running a non-wasm webserver that then proxies to WASM modules? Is that wasmedge? Or does wasmedge really make syscalls like accept() available to the module?

If it's the latter, how could it actually do something meaningful without threading - given any accept() would block the whole module? Run in non-blocking mode and expect the whole WASM module to be written in async style?

I know these are lots of questions - but they seem rather fundamental to what you could actually use the system for.



> Is this example running a non-wasm webserver that then proxies to WASM modules? Is that wasmedge? Or does wasmedge really make syscalls like accept() available to the module?

> If it's the latter, how could it actually do something meaningful without threading - given any accept() would block the whole module? Run in non-blocking mode and expect the whole WASM module to be written in async style?

The docs here show how it works: https://wasmedge.org/book/en/write_wasm/rust/networking.html


Yeah, I'm with you on this. I'm hoping that there is more to come soon that might flesh out this story. (I mean, surely just having an entrypoint into wasmtime + args or runtime of choice) gets these things inline with existing docker goals.

I think this is mostly a land grab to have docker image repositories be the distribution method of choice for wasi.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: