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

release runtime lock around syscalls #15

Open
edwintorok opened this issue Sep 27, 2023 · 0 comments
Open

release runtime lock around syscalls #15

edwintorok opened this issue Sep 27, 2023 · 0 comments

Comments

@edwintorok
Copy link
Collaborator

edwintorok commented Sep 27, 2023

Polly should probably release the runtime lock in a few more places, e.g. epoll_create1 and eventfd are both syscalls that may allocate resources and currently they'd block the entire process for their duration.
epoll_ctl is a syscall too, but it may be invoked very frequently (depending how the application) is written, so that one should probably be benchmarked whether releasing the runtime lock is beneficial or not (although in general we should probably release the runtime lock around any syscall - we don't know how long they might take).
The only place where keeping the runtime lock held is beneficial are small library functions that on their fastpaths don't invoke any syscalls.

Polly does release the runtime lock around the very long syscall that waits, so that is fine.

OTOH releasing the runtime lock makes optimizations like #12 impossible, so if we make changes in this area we should probably measure all 3 scenarios (current polly, noalloc polly, and polly with runtime lock released in _ctl), also measuring the impact on other threads that may be blocked.

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

No branches or pull requests

1 participant