Stream: git-wasmtime

Topic: wasmtime / PR #14320 `wasmtime serve`: Support multiple s...

Wasmtime GitHub notifications bot (Sep 11 2026 at 19:40):

simolus3 opened PR #14320 from simolus3:serve-unix-sockets to bytecodealliance:main:

This changes wasmtime serve to add support for

1. Listening on multiple sockets: wasmtime serve currently serves http requests from a single TCP server. This adds support for multiple server sockets, which is useful to e.g. listen for both ipv4 and ipv6 connections, e.g. with wasmtime serve app.wasm --addr 127.0.0.1:8080 --addr [::1]:8080. Multiple sockets can also be inherited via --systemd-listenfd.
2. Unix domain sockets. In setups where wasmtime serve runs behind a reverse proxy, using unix sockets instead of TCP is simpler and likely faster. With this PR, unix sockets can be inherited via --systemd-listenfd. This avoids having to parse both file paths and ip addresses from parameters, but maybe it makes sense to do that as well.

Support for multiple sockets is implemented by spawning one task per socket that otherwise runs the existing request loop. To avoid concurrency for debugging setup, that still runs outside of a concurrent task (and thus only supports a single socket).

Wasmtime GitHub notifications bot (Sep 11 2026 at 19:40):

simolus3 requested dicej for a review on PR #14320.

Wasmtime GitHub notifications bot (Sep 11 2026 at 19:40):

simolus3 requested wasmtime-core-reviewers for a review on PR #14320.

Wasmtime GitHub notifications bot (Sep 11 2026 at 19:48):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 14 2026 at 15:24):

:thumbs_up: dicej submitted PR review:

Thanks, @simolus3!

Wasmtime GitHub notifications bot (Sep 14 2026 at 15:24):

dicej added PR #14320 wasmtime serve: Support multiple sockets, unix sockets to the merge queue.

Wasmtime GitHub notifications bot (Sep 14 2026 at 15:43):

github-merge-queue[bot] removed PR #14320 wasmtime serve: Support multiple sockets, unix sockets from the merge queue.

Wasmtime GitHub notifications bot (Sep 14 2026 at 16:01):

dicej commented on PR #14320:

@simolus3 Looks like the Windows builds are failing due to ungated Unix-isms.

Wasmtime GitHub notifications bot (Sep 14 2026 at 16:13):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 14 2026 at 16:17):

simolus3 commented on PR #14320:

I didn't know we couldn't do cfg in pin-project-lite, I'm now using this workaround, I also had to mark StdSocketServer::Inet as unix-only since it's not constructed on Windows builds, leading to a warning. It's a hard for me to test locally since I don't have access to Windows, but I hope it works now.

Wasmtime GitHub notifications bot (Sep 14 2026 at 16:17):

simolus3 edited a comment on PR #14320:

I didn't know we couldn't do cfg in pin-project-lite, I'm now using this workaround. I also had to mark StdSocketServer::Inet as unix-only since it's not constructed on Windows builds, leading to a warning. It's a hard for me to test locally since I don't have access to Windows, but I hope it works now.

Wasmtime GitHub notifications bot (Sep 22 2026 at 19:05):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 22 2026 at 21:04):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 22 2026 at 21:07):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 22 2026 at 21:21):

simolus3 commented on PR #14320:

@dicej Could you take another look please?

Wasmtime GitHub notifications bot (Sep 22 2026 at 23:16):

:thumbs_up: dicej submitted PR review:

LGTM; just one comment inline.

Wasmtime GitHub notifications bot (Sep 22 2026 at 23:16):

:speech_balloon: dicej created PR review comment:

This line appears to be redundant given the #[cfg(unix)] on the pin_project!.

Wasmtime GitHub notifications bot (Sep 23 2026 at 06:45):

simolus3 updated PR #14320.

Wasmtime GitHub notifications bot (Sep 23 2026 at 13:32):

dicej added PR #14320 wasmtime serve: Support multiple sockets, unix sockets to the merge queue.

Wasmtime GitHub notifications bot (Sep 23 2026 at 13:59):

:check: dicej merged PR #14320.

Wasmtime GitHub notifications bot (Sep 23 2026 at 13:59):

dicej removed PR #14320 wasmtime serve: Support multiple sockets, unix sockets from the merge queue.

Wasmtime GitHub notifications bot (Sep 23 2026 at 14:13):

alexcrichton commented on PR #14320:

Is there precedent in other tooling for opening multiple sockets with multiple --addr-style arguments? I'd naively have expected one socket to be bound to multiple addresses, but I'm also not familiar with any tool that accepts multiple arguments.

Wasmtime GitHub notifications bot (Sep 23 2026 at 14:52):

simolus3 commented on PR #14320:

I'd naively have expected one socket to be bound to multiple addresses

Outside of a 0.0.0.0 dualstack address, is that possible? TcpListener::bind says "If addr yields multiple addresses, bind will be attempted with each of the addresses until one succeeds and returns the listener". My idea was that we might want to support passing paths for unix sockets to listen on in the future as well.

So this mostly seemed like the smallest change to get this to work, if this usage seems odd I can open another PR to change it. I didn't base this on any particular convention, but I found other tools with similar patterns, the docker daemon supports dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2 for example. dnsmasq and gunicorn also support the same pattern with multiple --listen-address and --bind arguments.

Wasmtime GitHub notifications bot (Sep 23 2026 at 14:52):

simolus3 edited a comment on PR #14320:

I'd naively have expected one socket to be bound to multiple addresses

Outside of a 0.0.0.0 dualstack address, is that possible? TcpListener::bind says "If addr yields multiple addresses, bind will be attempted with each of the addresses until one succeeds and returns the listener". My idea was that we might want to support passing paths for unix sockets to listen on in the future as well.

Is there precedent in other tooling for opening multiple sockets with multiple --addr-style arguments?

This mostly seemed like the smallest change to get this to work, if this usage seems odd I can open another PR to change it. I didn't base this on any particular convention, but I found other tools with similar patterns, the docker daemon supports dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2 for example. dnsmasq and gunicorn also support the same pattern with multiple --listen-address and --bind arguments.

Wasmtime GitHub notifications bot (Sep 23 2026 at 15:17):

alexcrichton commented on PR #14320:

I'm mostly just vaguely aware that binding multiple addresses is a thing, but if that's only intended for niche scenarios then it seems inapplicable here. If there's precedent elsewhere though that seems fine.

Looking at this change though, this looks like it breaks the --shutdown-addr option. The synchronization there was only workable for one connection as opposed to multiple, so the shutdown address only works for a single listener not multiple. It also looks like there are no tests for --addr being specified multiple times, only the inherit-multiple path.

Wasmtime GitHub notifications bot (Sep 23 2026 at 15:42):

simolus3 commented on PR #14320:

I think --shutdown-addr should still work because notify_waiters() notifies all tasks? The existing test also relies on that, but I'll look into it and will add a test specifying multiple addresses.

Wasmtime GitHub notifications bot (Sep 23 2026 at 16:18):

alexcrichton commented on PR #14320:

Looking again I think I manage to always confuse myself with tokio's Notify structure... I think there's definitely a bug where notify_waiters does nothing if there aren't actually any waiters (nothing is buffered). That's preexisting from before this, however, because if something wasn't actively waiting on .notified() then notify_waiters is a noop, so between when a connection is accepted and the task for the connection is spawned if a notify_waiters happens then nothing actually breaks out of the loop. I'll work on fixing this since it's a preexisting issue, but if you're willing to add a test with multiple --addr options that'd be appreciated yeah

Last updated: Oct 11 2026 at 02:20 UTC