Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add poll.check #75

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

add poll.check #75

wants to merge 2 commits into from

Conversation

guybedford
Copy link

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
Copy link
Member

Sounds reasonable to me.

@guybedford
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

badeend commented Jun 20, 2024

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

@guybedford
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants