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

task: quickly send task to heap on debug mode #4009

Merged
merged 2 commits into from
Aug 12, 2021

Conversation

blasrodri
Copy link
Contributor

Ref: #2055

Motivation

Solution

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-runtime Module: tokio/runtime labels Jul 30, 2021
@Darksonn
Copy link
Contributor

That's certainly one way to approach it. I have some ideas for alternatives, but I'm ok with merging this for now, possibly replacing it with another idea later if it works out.

Please note that we have multiple spawn methods. It would also be an idea to have a test that spawns a massive future to catch regressions in how large futures we can handle.

@blasrodri
Copy link
Contributor Author

Good idea! Do you want to include the regression test in this PR?

@Darksonn
Copy link
Contributor

Sure.

@blasrodri
Copy link
Contributor Author

That's certainly one way to approach it. I have some ideas for alternatives, but I'm ok with merging this for now, possibly replacing it with another idea later if it works out.

Please note that we have multiple spawn methods. It would also be an idea to have a test that spawns a massive future to catch regressions in how large futures we can handle.

Is there a way to get the limit value of the stack? I assume that the one running in the CI/CD is different than the one on my local machine. I can test a few, but perhaps there was a better way.

@Darksonn
Copy link
Contributor

The original issue had a link to a function called remaining_stack, but I don't think you can change the size of the future dynamically based on its value. A better alternative might be to go through the thread builder and set your own stack size directly.

@hawkw
Copy link
Member

hawkw commented Aug 1, 2021

Alternatively, couldn't we just make the majority of the functions the task is passed through be #[inline(always)]?

@Darksonn
Copy link
Contributor

Darksonn commented Aug 2, 2021

According to this comment, that apparently didn't help as much as you would hope.

@hawkw
Copy link
Member

hawkw commented Aug 2, 2021

@Darksonn huh, that's weird! never mind, then.

@blasrodri
Copy link
Contributor Author

blasrodri commented Aug 7, 2021

The original issue had a link to a function called remaining_stack, but I don't think you can change the size of the future dynamically based on its value. A better alternative might be to go through the thread builder and set your own stack size directly.

I'm trying to get back to this one, so it can be merged.
Your proposal is to set a fix stack through the builder, and then create a task that's equally big, right? I guess we also need to create a test set on the CI that sets the opt-level in order to reproduce the debug setup?

tokio/src/task/spawn.rs Outdated Show resolved Hide resolved
Co-authored-by: Alice Ryhl <alice@ryhl.io>
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 M-runtime Module: tokio/runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants