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

Document performance considerations tokio::fs #2700

Closed
Darksonn opened this issue Jul 25, 2020 · 8 comments
Closed

Document performance considerations tokio::fs #2700

Darksonn opened this issue Jul 25, 2020 · 8 comments
Labels
A-tokio Area: The main tokio crate C-maintenance Category: PRs that clean code up or issues documenting cleanup. 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-fs Module: tokio/fs T-docs Topic: documentation T-performance Topic: performance and benchmarks

Comments

@Darksonn
Copy link
Contributor

All file operations are currently spawned on a thread pool with spawn_blocking which is rather expensive. We should document these performance considerations a lot better than we are doing now.

Refs: #1976, #1844

@Darksonn Darksonn added E-help-wanted Call for participation: Help is requested to fix this issue. T-docs Topic: documentation E-easy Call for participation: Experience needed to fix: Easy / not much C-maintenance Category: PRs that clean code up or issues documenting cleanup. A-tokio Area: The main tokio crate M-fs Module: tokio/fs T-performance Topic: performance and benchmarks labels Jul 25, 2020
@lnicola
Copy link
Contributor

lnicola commented Jul 25, 2020

Is it possible to use block_in_place in their implementation? I suppose there's still some value in using tokio-fs, as it might get io_uring support in some nebulous future.

@Darksonn
Copy link
Contributor Author

Darksonn commented Jul 25, 2020

Using block_in_place is a massive footgun and will break any code that uses things such as select!, join! or join_all.

@LucioFranco
Copy link
Member

We likely want to create a section on the website for this. I am happy to contribute to this one.

@Darksonn
Copy link
Contributor Author

I opened an issue on the website repository too.

blasrodri added a commit to blasrodri/tokio that referenced this issue Jul 4, 2021
Add a note on some functoins/methods that belong to `fs`
to let the user  note that they are blocking, and
handled by spawn_blocking.

Ref: tokio-rs#2700
@Lol3rrr
Copy link

Lol3rrr commented Sep 11, 2023

It seems like this issue is no longer relevant (i think?), as the docs for fs mention that blocking tasks are spawned for the operations

@PaulDotSH
Copy link

Using block_in_place is a massive footgun and will break any code that uses things such as select!, join! or join_all.

What about having another API that specifically uses block_in_place, that users can use if they chose to, and that way we will both prevent having a breaking-change that breaks other uses, and both possibly let users benefit from performance improvements

@sfackler
Copy link
Contributor

That seems like a thing you can trivially do yourself with block_in_place and std::fs::File.

@Darksonn
Copy link
Contributor Author

Closing as fixed by #6467.

Tokio will not encourage use of block_in_place by providing such APIs.

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-maintenance Category: PRs that clean code up or issues documenting cleanup. 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-fs Module: tokio/fs T-docs Topic: documentation T-performance Topic: performance and benchmarks
Projects
None yet
Development

No branches or pull requests

6 participants