Add 'non-blocking' function attribute

[lukewagner]

This PR adds non-blocking to functype (both in WAT and WIT). It's a pretty small addition and doesn't touch validation/runtime.

While it initially seemed attractive to enforce non-blocking with trap-on-block semantics, there are valid scenarios where a callee might actually want/need to block and where the loss of concurrency in the caller is fine. Thus the PR proposes making non-blocking just a hint (ignored by validation/runtime) to inform bindings generation (e.g., allowing bindings generators that make all functions async by default emit non-async functions for non-blocking).

constructor implies non-blocking (since new expressions in most languages can't be async). However, to avoid breaking wasip2, we don't (yet) require validation of [constructor]-named functions to contain non-blocking (adding this to the list of warts to remove in the next breaking change). In any case, bindings generators can always just take the non-blocking hint directly from seeing [constructor].

[sunfishcode]

Could you add some text to Wit.md briefly describing what non-blocking does, from a Wit user perspective? And maybe link back to the Explainer.md for the full details?

[lukewagner]

Good idea, fixed, PTAL

[sunfishcode]

From a new Wit user perspective. the name "non-blocking" could sound like it means "no stopping the caller" rather than "no waiting for I/O", which would be confusing since it does the exact opposite of that :-}. At least we should clearly document the Wit-user-facing side of this keyword.

[lukewagner]

Yeah, I suppose "blocking" does have multiple interpretations. I added this addition to the previous note, but it could probably be improved.

[sunfishcode]

Is the "primarily" here redundant?

[lukewagner]

Yeah, I suppose so. It felt a bit off without any word, so I tried "only", and also tightened up the rest of the sentence in this commit, PTAL

[badeend]

Since this is just a hint for the binding generators and not actually enforced at runtime: as a WIT author I'd rather prefer the defaults to be swapped. I.e. functions should be generated as non-blocking by default unless told otherwise.

As an example I annotated the wasi-sockets proposal with both defaults:

• With "blocking" as the default, it needs 34 annotations
• With non-blocking as the default, it needs just 5.

Aside from the amount of work it is for me (which I can live with :P ), annotating only the "blocking" functions is more familiar to readers who have experience with async/await languages, since the concept maps pretty much 1:1.

[dicej]

Since this is just a hint for the binding generators and not actually enforced at runtime: as a WIT author I'd rather prefer the defaults to be swapped. I.e. functions should be generated as non-blocking by default unless told otherwise.

I said the same thing when @lukewagner and I discussed this a while ago. I believe his response was that constructors are non-blocking by convention and that, once WIT has special syntax for resource getters and setters, those will also be non-blocking by convention, which should reduce the number of explicit annotations required.

That said, I still tend to agree with you about swapping, since experience has show that functions in the average WIT interface that involve I/O are in the minority, even after you ignore the constructors, getters, and setters.

[lukewagner]

Scanning that wasi-sockets PR, 28 of the 34 non-blocking annotations would be removed by WIT getter/setter syntax.

For the case of connect, it seems like this should be blocking (as is, e.g., the Node.js API). For the case of disconnect, I may not understand this one fully, but the docs say it's equivalent to connect() with AF_UNSPEC, and since connect() is async, it seems like it should be blocking too?

For the case of bind (x2) and listen, I see there are corresponding IORING_OP_*s for these, so if one was using an io_uring-based implementation, there could hypothetically be concurrency wins from doing these async. In general, I've been imagining that the rough (but not hard) criteria for "should it be blocking?" is "does it require a syscall?" since this where a bunch of potentially-blocking and concurrent things can happen.

But for the last case, receive, this does seem like a case we might see more of where the returned tuple<stream<u8>, future<...>> (perhaps one day soon condensed down to a stream<u8, _, error-code> or something like that) captures all the asynchrony and so the non-blocking looks superfluous. One idea is that, in the same way as "constructors are implicitly non-blocking", we could say that "functions returning only futures+streams are implicitly non-blocking" too.

[badeend]

Regarding connect/disconnect: I suspect you're looking at the UDP variants. Those do not perform any IO, so their annotations are correct. Their unfortunate names are explained here.

As for bind (2x) & listen: those do not perform any IO either. It appears their io_uring opcodes were added recently. IIUC, the reason for inclusion in io_uring isn't to do with I/O but rather for interoperability with io_uring's "registered files" feature. My knowledge of io_uring is not sufficient enough to know how this would impact the WASI interface (if at all).

---

I've been imagining that the rough (but not hard) criteria for "should it be blocking?" is "does it require a syscall?"

I see your point (and the "but not hard" caveat), but I don't know how to extrapolate that guidance:

• All sockets options are syscalls too, so following that logic would imply they should all be blocking methods instead of getters/setters.
• From the component's POV, arent't all imports effectively "syscalls"?

---

Having native syntax for getters & setters could indeed help alleviate many of the annotations in wasi-sockets. As you already counted out, that would bring the amount of needed annotations down from 34 to just 6. Versus 5. So: potáto, potàto. 🙃

My other point still stands though; this is a syntax is directed at binding generators / language implementors. IMO it still makes sense to speak "their" language, not "ours". From a JavaScript/Python/Rust/C#/.. developer's POV, seeing an async annotation is instantly familiar and (aside from an edge case here and there) will probably map 1:1 to async in the generated bindings for their language. That being said, I realize this is purely syntactical bikeshedding so please don't block the PR on this, as I fully agree with the semantics. 👍