Avoid JSPI suspend on poll()/select() with zero timeout

[guybedford]

When using JSPI, it can be beneficial to have exported functions using poll that do not use WebAssembly.Promising wrappers. In order to achieve this, one would want access to the non-JSPI poll variant that does not use WebAssembly.Suspending.

This updates the implementation of poll to route to the non-suspending variant whenever a zero timeout is set. We could possibly guard this on JSPI only if we wish to as well.

This was useful for the Tokio prototype work to support both types of stacks at the same time.

[sbc100]

I wonder if we could just make poll with a timeout of zero never suspending?

If we did that would it address your concerns?

I think what we could need to do is have two internal functions __poll_blocking and __poll_nonblocking. Then the native __syscall_poll could call one or the other depending on the timeout value?

This would avoid declaring any new functions in the public API.

[sbc100]

We do have a precedent for writing "sometimes-suspending" functions. See #26947.

[sbc100]

Nice!

[sbc100]

lgtm % final nits

Its a little bit hard for me to the tell the that behaviour of the normal poll is unchanged, but I we have test coverage for I think.

[sbc100]

You will probably need to rebase the codesize tests (that only one I expect to see change is that one that include all JS functions).

[sbc100]

For the PR title, how about "Avoid JSPI suspend on poll()/select() with zero timeout" ?

[sbc100]

I enabled audo-merge so this should land once tests pass.