Current implementation of both fairPoll and unfairPoll has employed busy polling methods, which actively tries reading from non-blocking file descriptors and see if anyone returns other than EAGAIN.
While this approach works, it creates performance overhead which could in theory max out a processor core, slowing down the device as well as draining batteries (especially on mobile phone platforms).
Instead a better approach is using a poll-like approach (as mentioned in #1). WASI Preview 1 defines poll_oneoff which behaves like poll and blocks until at least an event subscribed to is triggered. (It does not support specifying a timeout, but we can subscribe to a clock event instead.)
Therefore, we should consider importing poll_oneoff or use the existing implementation. TinyGo is allegedly importing poll_oneoff but we are not seeing any non-trivial use case. golang/go is also importing poll_oneoff when implementing the netpoll function set on wasip1. We could possibly build a similar wrapper.
Current implementation of both
fairPollandunfairPollhas employed busy polling methods, which actively tries reading from non-blocking file descriptors and see if anyone returns other thanEAGAIN.While this approach works, it creates performance overhead which could in theory max out a processor core, slowing down the device as well as draining batteries (especially on mobile phone platforms).
Instead a better approach is using a
poll-like approach (as mentioned in #1). WASI Preview 1 definespoll_oneoffwhich behaves likepolland blocks until at least an event subscribed to is triggered. (It does not support specifying a timeout, but we can subscribe to a clock event instead.)Therefore, we should consider importing
poll_oneoffor use the existing implementation. TinyGo is allegedly importingpoll_oneoffbut we are not seeing any non-trivial use case.golang/gois also importingpoll_oneoffwhen implementing thenetpollfunction set on wasip1. We could possibly build a similar wrapper.