Skip to content

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

Merged
Darksonn merged 2 commits intotokio-rs:masterfrom
blasrodri:avoid-stackoverflow-on-debug-mode
Aug 12, 2021
Merged

task: quickly send task to heap on debug mode#4009
Darksonn merged 2 commits intotokio-rs:masterfrom
blasrodri:avoid-stackoverflow-on-debug-mode

Conversation

@blasrodri
Copy link
Copy Markdown
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
Copy Markdown
Member

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
Copy Markdown
Contributor Author

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

@Darksonn
Copy link
Copy Markdown
Member

Sure.

@blasrodri
Copy link
Copy Markdown
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
Copy Markdown
Member

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
Copy Markdown
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
Copy Markdown
Member

Darksonn commented Aug 2, 2021

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

@hawkw
Copy link
Copy Markdown
Member

hawkw commented Aug 2, 2021

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

@blasrodri
Copy link
Copy Markdown
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?

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