WebAssembly on the Server: How System Calls Work
summary
A tiny runtime called dagger exposes five system calls — open, close, read, write, flush — implemented in about 500 lines of code and enough to run an HTTP client and simple services. Streams cover logging, jailed file access, http(s), randomness and stdio. A Zig hello world uses ~128k RAM and runs, and the runtime supports VM snapshot/restore; control streams, TCP accept and a gopher-per-module idea are proposed.
AI-written summary · about
chapters (20)
- 0:00Introduction to talk
- 0:48What is WebAssembly
- 1:52Why WebAssembly on server
- 2:34Why system calls matter
- 3:16WebAssembly system calls basics
- 3:58Pointers in WebAssembly
- 4:40Introducing Dagger concept
- 5:22Dagger process and streams
- 6:04Opening streams in Dagger
- 7:08Closing streams in Dagger
- 7:31Reading from streams
- 8:12Writing to streams
- 9:42Flushing streams
- 10:09Hello World example
- 11:14Future plans for Dagger
- 12:42Production use cases
- 13:04Transactional computing idea
- 13:26How to experiment with Dagger
- 13:49Gopher server concept
- 14:11Q&A and acknowledgments
related talks
52mWebAssembly: Taking Your C++ and Going Places
44mWebAssembly: the browser is now a real virtual machine
50mWeb Assembly
38mWebAssembly for the backend
13mWebAssembly & Syscalls: A Story in Tool-Building
25mWebAssembly: Binary in Plain English
53mWebAssembly
40mWebAssembly - The Future of Distributed Computing