[0.3.0-draft] Consider making `{tcp,udp}-socket.bind` `async`

[dicej]

Currently, these are synchronous functions, which makes sense given that they don't inherently involve I/O or blocking. However, they do perform a non-trivial operation that affects the state of the host system, and it's plausible that e.g. a browser polyfill might need to do some form of asynchronous operation to implement it. Additionally, a host might wish to restrict this operation to certain IP addresses or ranges, the validation of which might involve some form of blocking (e.g. to read configuration from a database).

Given that the component model will soon promote the async keyword from WIT-level sugar to part of the type system, with trapping behavior for non-async exports which try to block, we'll need to be more careful about declaring non-async functions in WIT. Therefore, the conservative choice when in doubt (i.e. if there's any chance the implementation might need to block) is to add async. An async function is always allowed to return without blocking, but a non-async function is never allowed to block prior to returning a result.

[badeend]

Sorry, most of this comment is about the proposed CM change, not actually the bind question. But I feel like I'll need to understand the CM changes a bit better before I can properly address the socket change.

I've read the linked diff once. And I guess I'll need to read a couple more times, but at the moment I don't understand.

These statements seem contradicting to me:

both sync-ABI-calls-async-ABI and async-ABI-calls-sync-ABI pairings have well-defined, composable behavior for both inter-component and intra-component calls.

and:

When a function type does not contain async, the Component Model traps at runtime if the callee potentially blocks

I suppose trapping is well-defined, but I wouldn't call it "composable".

---

the conservative choice when in doubt (..) is to add async

Because async exports impose little to no requirements (..), most worlds (..) are expected to export async functions (..)

IIUC, not marking a function async will hurt async-over-sync/sync-over-async composability, so we're encouraged to mark as much async as possible in the off-chance that someone somewhere may want to block?

system-clock::now() performs I/O. Should it become async as well? It isn't in the browser.

---

Thus, async in WIT does not have the same "infective" property as async in langauges like C#, Python, JS, Rust and Dart (..)

Hmm, it's only not infectious if indeed everything is marked async. Otherwise it still suffers from exactly the same function coloring, right?

---

POSIX bind is synchronous, so won't this trap when attempting to synchronously call the async WASI equivalent?

Currently, these are synchronous functions, which makes sense given that they don't inherently involve I/O or blocking

Correct. The rationale was that binding a socket in itself indeed does not do any I/O nor does it grant the guest any communication with the outside world. The idea was that if the host wants to block for e.g. permission checks, then they can do so on the first attempt to actually communicate (listen or connect, which are async)

[dicej]

Thanks for your comments and questions, @badeend. @lukewagner can hopefully provide more background regarding the proposed spec changes, but I'll address a few points here:

POSIX bind is synchronous, so won't this trap when attempting to synchronously call the async WASI equivalent?

We can always implement synchronous (e.g. blocking read or write) functions in wasi-libc using waitable-set.wait, possibly in combination with cooperative multithreading.

Currently, these are synchronous functions, which makes sense given that they don't inherently involve I/O or blocking

Correct. The rationale was that binding a socket in itself indeed does not do any I/O nor does it grant the guest any communication with the outside world. The idea was that if the host wants to block for e.g. permission checks, then they can do so on the first attempt to actually communicate (listen or connect, which are async)

Yeah, I had the same idea of delaying the check until listen or connect, but decided to lead with the async bind approach as being potentially more future-proof since we can't really change our minds once 0.3.0 ships. Anyway, I'm personally fine with delaying the check until listen/connect. @alexcrichton do you have any concerns with that approach?

BTW, regarding the proposed CM spec changes: the async term is being overloaded to mean two distinct things:

• In the context of a function type, it indicates whether an implementation is allowed to perform a blocking operation (i.e. async means it's allowed to; otherwise it will trap). (Technically the host can use its superpowers to block anyway, but that must be invisible to the guest.)
• In the context of the function lifting and lowering ABI, it indicates whether the core function is using the async or sync lift or lower ABI. Note that an async-typed function may be lifted or lowered async or sync, and likewise a sync-typed function may be lifted or lowered async or sync.
  • In the context of binding generation, it indicates whether to generate async or sync lifts and/or lowers by default

In other words, what async means depends on whether we're talking about the type or the lift/lower ABI, and they're somewhat orthogonal to each other.

[alexcrichton]

@alexcrichton do you have any concerns with that approach?

For shipping p3, I'm not sure this will be sufficient after all.

For wasi:sockets in the abstract I'm wary of straying further and further from berkely-sockets-style-APIs since that's what's implemented on every host and what's expected on every guest. The more we deviate the more that hosts have a possibility for bugs and guests have to have more code to handle the difference. Not a dealbreaker per se, but I think we should try really hard to not stray from what's expected by guests and what's provided on hosts.

[dicej]

OK, sounds like this is not the way forward for multiple reasons; will close.