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 the optional argument of the Task constructor #55005

Closed
nsajko opened this issue Jul 2, 2024 · 5 comments · Fixed by #55184
Closed

document the optional argument of the Task constructor #55005

nsajko opened this issue Jul 2, 2024 · 5 comments · Fixed by #55184
Labels
docs This change adds or pertains to documentation

Comments

@nsajko
Copy link
Contributor

nsajko commented Jul 2, 2024

The optional Int parameter seems to determine the stack size of the Task, but its not documented at all.

Core.Task(@nospecialize(f), reserved_stack::Int=0) = Core._Task(f, reserved_stack, ThreadSynchronizer())

@nsajko nsajko added the docs This change adds or pertains to documentation label Jul 2, 2024
vtjnash pushed a commit that referenced this issue Jul 25, 2024
Fixes #55005 and helps work
around issues discussed in
#54998.
@nsajko
Copy link
Contributor Author

nsajko commented Jul 25, 2024

The nice thing about making the Task stack size limit public, is that now it'll be possible to run with a smaller size within the test suite of a package, to catch potential issues early, e.g., overly deep recursion.

@vtjnash
Copy link
Member

vtjnash commented Jul 25, 2024

Just as a warning though, you will consume substantially more memory (both physical and virtual) if you use this option, as it forces eager allocation of a stack that may never get used. Use with some care.

@nsajko
Copy link
Contributor Author

nsajko commented Jul 25, 2024

Oh. I didn't think it'd work like that.

@MilesCranmer
Copy link
Member

Just as a warning though, you will consume substantially more memory (both physical and virtual) if you use this option, as it forces eager allocation of a stack that may never get used. Use with some care.

It feels surprising that memory is allocated differently between default stack size limit and custom stack size limit. How hard would it be to turn off eager allocations here?

@MilesCranmer
Copy link
Member

I'm also confused because

julia> Task(() -> sleep(10), 10 * 1024 ^ 4)  |> schedule |> fetch

doesn't OOM...

lazarusA pushed a commit to lazarusA/julia that referenced this issue Aug 17, 2024
Fixes JuliaLang#55005 and helps work
around issues discussed in
JuliaLang#54998.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants