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
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.
The text was updated successfully, but these errors were encountered:
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.
File handle access is currently controlled using an
MVar
, guaranteeing exclusive access to a file handle. However, this is unnecessarily restrictive: functions likehGetSomeAt
can read from file handles without modifying the contents of the file or the current file offset.The text was updated successfully, but these errors were encountered: