Support listening to a port during initialization

[joshtriplett]

In theory, wizer could support a call to open a listening socket during initialization. The call would get recorded as a listening port, and when the resulting module is later loaded, the loader could listen on that port and make the resulting socket available as the same file descriptor. If the module calls accept, or if it checks the listening port number without first setting that port number, that would prevent initialization from progressing past that point. But otherwise, the initialization could progress past the call to listen, and the resulting wizened module could be used with a pre-opened socket.

[fitzgen]

Agreed this would be cool! But ports are more of a WASI and host concern than a Wizer-itself concern. I'd expect WASI to define an API for working with ports, and then the build and production environments would have an agreed-upon scheme for reusing+preinitializing fds for the wizened module.

[joshtriplett]

@fitzgen It's definitely not wizer's job to define port handling, and I agree that part would go on the WASI side. I mentioned this more because it seemed like a good fit with the node-style server function used as a flagship example.

Once WASI has socket listen/accept support, the only thing I'd expect from wizer would be hooking that to allow it to happen during initialization. In general, wizer could have handling for specific cases of "open thing ... do something with thing" patterns, allowing the "open thing" step and the code coming after it to happen during initialization, and then requiring an already-opened thing to be passed into the initialized module. Listening on a port is just one example of an "open thing" step.

(Separately, it'd absolutely be possible to wizen a module that always expects to have a socket passed in, in which case wizer doesn't have to know about it at all.)

[fitzgen]

I would say that is supported today, in the sense that the open socket would be an integer fd today, and wizer would have no trouble preserving it after initialization. It would be 100% the host's job to prepopulate its tables such that the fds are the "same".

Once WASI uses reference types for resources, instead of integer fds, there will be more work to do in Wizer itself to support snapshotting reference types.