runtime,syscall,internal/poll,os: wasip1 poll_oneoff scheduler integration + net.FileListener

[achille-roussel]

On wasip1 today every syscall.Read/Write blocks the entire wasm module — the cooperative scheduler invokes poll_oneoff only for sleep/timer wakeups, and there's no path from the net package to a working TCP server. This PR fixes both: it threads poll_oneoff through the scheduler's idle path so a goroutine doing FD I/O parks instead of blocking the module, and it provides enough internal/poll / os / syscall surface that upstream Go's net.FileListener / net.FileConn works on a host-pre-opened TCP socket.

End to end:

$ tinygo build -target=wasip1 -o tcpecho.wasm ./tcpecho.go
$ wasmtime run -Spreview2=false -Stcplisten=127.0.0.1:9999 ./tcpecho.wasm &
listening on FD 3

$ echo hello | nc 127.0.0.1 9999
hello                                  # echoed by the wasm

Concurrent connections work too — multiple nc clients hit the server back-to-back; both got accepted and echoed while the cooperative scheduler kept running goroutines parked on sock_recv. The tcpecho.go source is the minimal upstream-Go-idiomatic TCP echo server, no TinyGo net override required:

f := os.NewFile(3, "tcplisten")
ln, _ := net.FileListener(f)
for {
    c, _ := ln.Accept()
    go func(c net.Conn) { defer c.Close(); io.Copy(c, c) }(c)
}

Architecture

The cooperative scheduler's idle path now calls poll_oneoff with one combined subscription array: a clock subscription for the next timer/sleep deadline, plus one FD subscription per goroutine that's parked waiting on I/O.

syscall.Read / Write   ─EAGAIN─►  internal/poll registry  ─►  task.Pause()
                                          │
                                          ▼
                    scheduler idle  ──►  pollIO(timeoutNs)
                                          │
                                          ├─ build subs: [clock, fd1, fd2, …]
                                          ├─ poll_oneoff(...)
                                          └─ wake matched tasks → run queue

Upstream net's net.FileListener(f) flow plumbs through these layers:

1. (*os.File).PollFD() returns a cached *poll.FD stored in a new pfd pollFD field on the shared file struct. pollFD is a per-target alias — *poll.FD on wasip1, literal struct{} (zero bytes, non-trailing) on every other target.
2. (*poll.FD).Copy() increments a SysFile refcount so f.Close() and ln.Close() cooperatively release the syscall FD.
3. Upstream net/file_wasip1.go calls fd_fdstat_get_type (linknamed into our syscall) to detect FILETYPE_SOCKET_STREAM.
4. Listener.Accept → (*poll.FD).Accept → syscall.Accept → sock_accept wasmimport. EAGAIN parks the goroutine via the runtime netpoll registry.
5. Conn.Read/Write see isSocket() == true (cached SysFile.Filetype) and dispatch to sock_recv / sock_send direct wasmimports with park-on-EAGAIN + deadline support.
6. Conn.Close triggers Shutdown (→ sock_shutdown) and refcount-aware Close.

Non-goals (deferred)

• net.Dial("tcp", ...), net.Listen("tcp", ...) — wasip1 has no sock_connect / bind / listen (only sock_accept / recv / send / shutdown). Outbound TCP requires the wasi-sockets proposal (preview2+) or a runtime-specific extension. The relevant stubs return ENOSYS so callers see a clean error.
• UDP / PacketConn — upstream's filePacketConn returns ENOPROTOOPT on wasip1.
• DNS resolution — FileListener / FileConn paths bypass the resolver entirely.
• wasip2 — uses pollable resources, structurally different. Future PR.

[achille-roussel]

@dgryski @jakebailey any feedback on this change?

[jakebailey]

I don't think I have the required experience here, though I have a bad feeling that these wasip1 calls might not be fully implemented on some hosts and break people running stuff in a browser, e.g. https://github.com/bjorn3/browser_wasi_shim/blob/b068ec2c22d68581c48f2592f8cca1681bf71a98/src/wasi.ts#L837

[achille-roussel]

poll_oneoff is part of the standard (and frozen) wasip1 spec, wazero and wasmtime implement them, and big-Go relies on it as well.

If some random wasip1 port decided not to be spec-compilant, that's unfortunate but maybe better to fix those than limit TinyGo, what do you think?

[jakebailey]

You asked for my feedback! 😄

If BigGo does it, then fine; that's what I use with the above library anyway, so I must be avoiding using net anyway.

[achille-roussel]

I didn't mean to sound like I discarded your feedback, you called out the right risk here, I just wanted to share more info that I had to make sure we were aligned, thanks for calling it out!

[jakebailey]

Yes, sorry, don't take my joking seriously 😅