The name poll-one is very easily confused with poll-oneoff, the
previous name of poll-list during WASI preview 1 and much of the
development of Preview 2.
So, to resolve this confusion, poll-one has become the method
pollable.block().
Finally, poll-list has been renamed to poll, because there is no longer any ambiguity (relative to poll-one) about what the structure we are polling is. Personally I think it is nice to have landed in a spot where WASI poll has the same name as posix's poll(2).
The other justification for poll-list to have a distinct name was the anticipation of a future epoll-like poll-set. That future development is still available, without any compromise, by introducing some future epoll-like interface as a resource, e.g. resource poll-set { add: func(pollable, some-identifier) -> result; block() -> list<some-identifier>; ...}. But, right now we have a general consensus of YAGNI - we will get to Component Model async before we end up needing to amortize the construction of the list<borrow<pollable>> passed to poll, and that will in turn change some of the design calculus enough that it is currently premature to optimize.
The name
poll-oneis very easily confused withpoll-oneoff, the previous name ofpoll-listduring WASI preview 1 and much of the development of Preview 2.So, to resolve this confusion,
poll-onehas become the methodpollable.block().Inspecting if a poll is ready without blocking was requested in https://github.com/WebAssembly/wasi-io/issues/51. This is exposed as the method
pollable.ready() -> bool.Finally,
poll-listhas been renamed topoll, because there is no longer any ambiguity (relative topoll-one) about what the structure we are polling is. Personally I think it is nice to have landed in a spot where WASIpollhas the same name as posix'spoll(2).The other justification for
poll-listto have a distinct name was the anticipation of a future epoll-likepoll-set. That future development is still available, without any compromise, by introducing some future epoll-like interface as a resource, e.g.resource poll-set { add: func(pollable, some-identifier) -> result; block() -> list<some-identifier>; ...}. But, right now we have a general consensus of YAGNI - we will get to Component Model async before we end up needing to amortize the construction of thelist<borrow<pollable>>passed topoll, and that will in turn change some of the design calculus enough that it is currently premature to optimize.