Skip to content

release runtime lock around syscalls #15

Description

@edwintorok

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions