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

Draft: reuse allocated buffer in stream reads for TCP/Unix sockets #3411

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

seigert
Copy link
Contributor

@seigert seigert commented Mar 20, 2024

Similar to #3318 I've changed implementation of SocketPlatform.BufferedReads to reuse allocated ByteBuffer for consecutive reads until filled.

Also I've moved maximum size of read chunk for Socket.reads method to constuctor parameter and made both read and write mutexes optional. Motivation is that if you primary use Socket instance exclusively by reading/writing from one client via either reads/writes or chain of .flatMap then your underlying Channel access is exclusive 'enough' to opt out of mutex guards.

The same logic applies to move of mutex locking for 'reads/writes' over stream itself instead of read/write of separate stream chunk: if we reading from or writing into socket with stream, I think we intend to do this without interleaving with other concurrent reads of writes, if any.

This PR is a draft, because there is still need to change usage of AsyncSocket in UnixSockets and add some tests for implementation without guards.

If this proposed change is acceptable, I'll finish the changes and add tests.

@armanbilge
Copy link
Member

I don't want to hold up this work since no ETA for Cats Effect 3.6, but note that these implementations are about to change.

@armanbilge armanbilge marked this pull request as draft March 20, 2024 18:13
@seigert
Copy link
Contributor Author

seigert commented Mar 20, 2024

I don't want to hold up this work since no ETA for Cats Effect 3.6, but note that these implementations are about to change.

Thanks for the heads up!

I've checked your PR and think that it is quite tangential to this one: while implementation of readChunk/writeChunk changes for sure, stream reads/writes looks unchanged, and so the questions of 'should we reuse/reallocate buffers' and 'should be guard each read/write op with mutex or stream as a whole' remain.

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

Successfully merging this pull request may close these issues.

2 participants