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

Several AsyncRead impls unnecessarily zero buffers in prepare_uninitialized_buffer #2308

Closed
Luexa opened this issue Mar 9, 2020 · 0 comments · Fixed by #2525
Closed

Several AsyncRead impls unnecessarily zero buffers in prepare_uninitialized_buffer #2308

Luexa opened this issue Mar 9, 2020 · 0 comments · Fixed by #2525
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-io Module: tokio/io M-process Module: tokio/process T-performance Topic: performance and benchmarks

Comments

@Luexa
Copy link

Luexa commented Mar 9, 2020

Version

tokio 0.2.13

Platform

This is an issue for all platforms.

Subcrates

I haven't reviewed the full source, but I've reviewed process and can confirm that the ChildStdout and ChildStderr types are affected.

Description

ChildStdout and ChildStderr implement AsyncRead by deferring to an internal PollEvented of a platform specific type: UNIX uses the standard library's child streams with EventedFd and Windows uses NamedPipe from mio_named_pipes. PollEvented naturally cannot implement prepare_uninitialized_buffer in any way other than zeroing, due to std::io::Read::initializer being unstable, however ChildStdout and ChildStderr use well-behaved types internally and should be known not to read from the buffer. Thus, the buffer needs not be initialized and prepare_uninitialized_buffer should be overwritten for these types to be a no-op.

Currently this bug affects me because I cannot call prepare_uninitialized_buffer due to the unacceptable zeroing, despite this being part of the contract of AsyncRead when an uninitialized buffer is involved. I just have to assume that the tokio implementation will remain well-behaved.

@Darksonn Darksonn added A-tokio Area: The main tokio crate C-bug Category: This is a bug. E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue. M-io Module: tokio/io M-process Module: tokio/process T-performance Topic: performance and benchmarks labels Apr 29, 2020
@Darksonn Darksonn removed E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue. labels Jul 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-io Module: tokio/io M-process Module: tokio/process T-performance Topic: performance and benchmarks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants