add poll.check

[guybedford]

There might still be a use case for non-blocking poll list as previously discussed in #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.

[sunfishcode]

Sounds reasonable to me.

[guybedford]

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]

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.

[badeend]

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

[guybedford]

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.