Let IO#sync only affect writes, introduce IO#read_buffering?
and use it in urandom
#6304
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #6303
Being able to disable read buffering for
IO::Buffered
is good. However, havingsync
affect both reads and writes makes it easier to enable just buffering for one direction: for sockets it's better to not have write buffering by default, so whatever you write goes directly to the socket (you can always setsync = false
and manually flush, which is what we do in a few places), but reads should always be buffered for performance reasons.With this PR we could release 0.25.2 as a bugfix release for this performance regression.
Then for 0.26.0 we could rename
sync
towrite_buffering
, or just leave it assync
. Maybewrite_buffering
is more explicit, even though it's a breaking change. But then, disabling read buffering is a very uncommon use case (urandom... what else?), so maybe havingsync
andread_buffering
as separate, asymmetric properties isn't that bad.(I know I could have used
getter
orsetter
for this, but given thatsync
doesn't use them I decided to follow that style. If someone wants to do a follow up PR to "improve" that (it's not really an improvement, because macros are slower to compile and it's just one/two line differences), then please go ahead).