wasi-io icon indicating copy to clipboard operation
wasi-io copied to clipboard

add poll.check

Open guybedford opened this issue 1 year ago • 5 comments

There might still be a use case for non-blocking poll list as previously discussed in https://github.com/WebAssembly/wasi-io/issues/51.

If there are a list of polls on which you want to check readiness, iterating the list and calling pollable.ready() for each one can work just fine, but it could be nice to optimize out the unnecessary set of host calls by having a list variant of this call.

guybedford avatar Mar 20 '24 18:03 guybedford

Sounds reasonable to me.

sunfishcode avatar Mar 20 '24 22:03 sunfishcode

This may be unnecessary after all - when implementing an event loop, computation work is maximized before suspending to tasks, so that having a distinction between a potentially indeterminate delay (poll) versus guaranteeing no delay (check) is not practically needed.

It is somewhat surprising to me that JS event loops exhaust CPU work over IO work, without interleaving immediately ready IO into the CPU processing model, but that does seem to be the case AFAICT. //cc @tschneidereit

That said, there may be other use cases for this host call that can be identified to justify it further.

guybedford avatar Apr 30 '24 01:04 guybedford

Updating my thoughts on this again - in the latest event loop model in StarlingMonkey this would in fact be useful.

We have a function - run_event_loop, which will run the event loop while there is external interest in it. Interest is determined by tracking a counter and decrementing it when tracked events happen. But there is also the concept of running the event loop with no interest. And in this case, we spin a single "tick", but don't want to wait on async tasks that might cause unnecessary stalling. Thus, having a check function would be useful in the single ticking non-interest case for the event loop.

guybedford avatar May 29 '24 22:05 guybedford

Maybe this can be merged with #76, as this non-blocking behavior is essentially the same as a timeout of 0?

badeend avatar Jun 20 '24 11:06 badeend

I think the argument is that timeouts can always be supported by having a timeout poll in the list, so it may be harder to justify shipping #76 than this feature.

guybedford avatar Jun 20 '24 22:06 guybedford