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

Provide Input.readTo(Buffer) #83

Closed
qwwdfsad opened this issue Nov 26, 2019 · 4 comments
Closed

Provide Input.readTo(Buffer) #83

qwwdfsad opened this issue Nov 26, 2019 · 4 comments
Assignees

Comments

@qwwdfsad
Copy link
Member

With best-effort zero-copy

@qwwdfsad qwwdfsad self-assigned this Nov 26, 2019
@altavir
Copy link

altavir commented Nov 28, 2019

Buffer should be treated as an internal object because it could cause a lot of damage if leaked. I prefer not to expose it if possible. This method if implemented should be internal and used inside Input to read to Bytes.

@qwwdfsad
Copy link
Member Author

qwwdfsad commented Nov 28, 2019

I am not sure how things you said interfere with my proposal.
We have Input.readArray(array), why can't we have Input.readTo(Buffer) as well? Nothing dangerous in this particular method.

The idea is to make it best effort zero-copy, if Input does not have anything pre-cached, so it will be possible to .g. have zero-copy LimitingInput using only public API.

@altavir
Copy link

altavir commented Nov 28, 2019

The Buffer should not be exposed at all since it is quite easy to mess with its disposal. It's appearance in public API could be tempting to something wrong. I do not see a way to implement zero-copy limits via filling buffer from the input because Input class does not allow to send your own buffer inside it. So even if you can directly read from input to buffer, this buffer is created by another input.

The method should be useful for internal API though. But in order to use it properly, we also need a way to hack into a way Input generates those Buffers.

@fzhinkin
Copy link
Collaborator

We're rebooting the kotlinx-io development (see #131), all issues related to the previous versions will be closed. Consider reopening it if the issue remains (or the feature is still missing) in a new version.

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

3 participants