You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Polly should probably release the runtime lock in a few more places, e.g.
epoll_create1
andeventfd
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.
The text was updated successfully, but these errors were encountered: