lindig / polly

OCaml bindings for Linux epoll(2)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

release runtime lock around syscalls

edwintorok opened this issue · comments

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.