Add 'non-blocking' function attribute #442
Conversation
lukewagner
force-pushed
the
non-blocking
branch
from
9bc797b to
c8be8a4
Compare
lukewagner
force-pushed
the
non-blocking
branch
from
c8be8a4 to
d1db043
Compare
| @@ -1295,7 +1296,7 @@ typedef-item ::= resource-item | |||
|
|
|||
| func-item ::= id ':' func-type ';' | |||
|
|
|||
| func-type ::= 'func' param-list result-list | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Good idea, fixed, PTAL
| ``` | ||
| If a resource-type has a potentially-blocking constructor, it can simply use | ||
| `static new: func(...) -> my-resource` instead; `constructor` has no advantages | ||
| beyond more-idiomatic bindings generation in some languages. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah, I suppose "blocking" does have multiple interpretations. I added this addition to the previous note, but it could probably be improved.
design/mvp/Explainer.md
Outdated
| a `valtype`. | ||
| a `valtype`. Function types can optionally be annotated with a `non-blocking` | ||
| attribute which has no semantic effect and is ignored at validation- and | ||
| run-time, serving primarily as a hint that tells bindings generators to lift |
There was a problem hiding this comment.
Is the "primarily" here redundant?
There was a problem hiding this comment.
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
lukewagner
force-pushed
the
non-blocking
branch
from
3bdea27 to
c81fbb2
Compare
This PR adds
non-blockingtofunctype(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-blockingwith 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 makingnon-blockingjust a hint (ignored by validation/runtime) to inform bindings generation (e.g., allowing bindings generators that make all functionsasyncby default emit non-asyncfunctions fornon-blocking).constructorimpliesnon-blocking(sincenewexpressions in most languages can't be async). However, to avoid breaking wasip2, we don't (yet) require validation of[constructor]-named functions to containnon-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].