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

Use reader/writer locks for access to file handles #49

Open
jorisdral opened this issue Mar 18, 2024 · 1 comment
Open

Use reader/writer locks for access to file handles #49

jorisdral opened this issue Mar 18, 2024 · 1 comment

Comments

@jorisdral
Copy link
Collaborator

jorisdral commented Mar 18, 2024

File handle access is currently controlled using an MVar, guaranteeing exclusive access to a file handle. However, this is unnecessarily restrictive: functions like hGetSomeAt can read from file handles without modifying the contents of the file or the current file offset.

@dcoutts
Copy link

dcoutts commented Mar 18, 2024

Uses of hGetSomeAt should be able to use a reader lock because they're safe to use concurrently with other "at" actions on the same file. They don't share a current file position.

So close would take a writer lock, and all the IO actions that modify the file position would do so to.

Note that the Win32 impl currently does share a file position, even for the "at" functions, so the Win32 impl would still have to use an ordinary lock.

In principle this could improve the file serving performance of Cardano relays. In particular, nodes get a lot of requests for the same block shortly after they announce a new block. These will all get served from the same open file in the volatile DB. Currently these will all serialise because they have to take the lock. This will prevent scaling of serving across multiple cores.

In practice that currently wouldn't make a lot of difference because most nodes only run with two capabilities, but running with more is possible.

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

2 participants