WASIp3 socket construction is infallible

[alexcrichton]

Reviewing some wasi:sockets code for WASIp3 I notice that there's now a constructor for udp-socket for example, but that means, curently, that the constructor is infallible. This means that host-level errors must be exposed as traps instead of error-codes.

[badeend]

Hmm, yeah. This might be a good use case for fallible constructors in the component model.

Instead of trapping, wasmtime could create the socket resource that is immediately in the TcpState::Error(..) state. Do you think this is a reasonable alternative?

Aside from EMFILE/ENFILE, failures from socket(..) should be uncommon.

[alexcrichton]

Yeah given that #129 is intentional we'll have an error state regardless so I'll update the implementation to unconditionally create a socket in the error state upon failure. In the meantime though to avoid creating a dependency between WASIp3 and fallible constructors if the desire is to expose fallible construction it might be best to switch to create: static func(...) -> result<...> or similar to create a "hole" for a fallible constructor to eventually fill.

[badeend]

See: #130

I went with new instead of create, because that's what wasi-http uses too.

[alexcrichton]

Fixed now.

[badeend]

@alexcrichton I realize the new syntax landed just yesterday in wasmtime, but do you reckon the 0.3 wasi-sockets interface can change back to constructors before the 0.3.0 launch?

[alexcrichton]

I think that'd be reasonable yeah. We'll need to be careful to ensure that everything is in a row tooling-wise (e.g. everything is updated everywhere to the latest wasm-tools). For example beta Rust right now supports component-model-async, but would fail if this were part of 0.3.0. This effectively would reset the timer of "time to when WASIp3 is supported in tooling" back to the start.

That's all just something to consider though. AFAIK we're still aiming for November-ish having things finalized so resettting the timer now is just something to be aware of. I think it'd be reasonable to shoot to have this in the next WASIp3 snapshot.

[badeend]

I've created #136 that performs a hard switch to the new syntax.

beta Rust right now (...) would fail if this were part of 0.3.0

Would Rust have problems if fallible constructors were used at all in the final 0.3.0 release? Or only if it were used in the upcoming 0.3.0 RC?
TBH, I don't know enough about Rust's release schedule to understand the implications. If you say it should be fine, then I'll take your word for it ;)

Just thinking out loud: Would it help for the short term (e.g. only the next RC), to have both the static create method (deprecated) and the new constructor in the same interface and drop the static method before the final 0.3.0? Or would the additional churn only complicate matters?
Edit: in either case, the tooling will need to update to the latest wasm-tools in order to grok the previously-invalid syntax. So I guess that answers my own question :)

[alexcrichton]

Yeah the main problem is that wasm-tools, or wit-parser, is embedded very deeply in a lot of places and takes awhile to update. For Rust everything flows through wasm-component-ld which uses wit-component which uses wit-parser. This wasm-component-ld binary is distributed along with the Rust compiler itself, so while I've now gone an updated it in nightly Rust that means that stable and beta do not have an updated wasm-component-ld to process fallible destructors. The wasi-sdk releases are in a similar situation (there's no release with a version of wasm-component-ld that supports fallible destructors)

That means that practically no one will be able to use WASIp3 if it requires a feature that hasn't actually propagated anywhere. This isn't a problem when you can say "make sure you're using version X" for a tool in question, so for example we could make a release of wasi-sdk today and we'd be ok. Rust's release process is out of our control, however, and we have 6-12 weeks until the current nightly hits stable at which point we can say "make sure you're using Rust version X for WASIp3".

AFAIK no one's positioned to render judgement on "yes now's the time to switch" so we're left to basically piece all the consequences together and make a local decision. As-is we do not have widespread adoption of WASIp3 and we're also not on the eve of the release which is saying "everyone go use stable toolchains!". Given that, in my opinion, we have runway (til November ish) to make changes like this in wasm-tools and rely on them. In a sense though the window is closing fast on that.

Would it help for the short term (e.g. only the next RC), to have both the static create method (deprecated) and the new constructor in the same interface

Unfortunately not. While I'd have to test to make sure I'd suspect that just simply having the fallible destructor would cause old tooling to choke as opposed to skipping over it. Given that the mere presence in official WITs is enough to invalidate older tooling, so having both would be a no-go if having just fallible constructors was also a no-go.

---

Overall I think I might actually be changing my own mind here, I might recommend against using it for the initial WASIp3 release. That'll give time for tooling to percolate, bindings generators to catch up, etc. I say this mostly because this is a relatively minor and cosmetic change that otherwise has no impact, so the downside of not including this is minor.

[badeend]

Okay! Let's defer this then. It's only a cosmetic change. I'll leave the PR open in draft for a 0.3.x release (where x>0).