Stack usage when using task::unowned in debug builds

[sander2]

Version
Tokio 1.12

Platform
Linux kernel 5.11 (Ubuntu)

Description

I ran into a stack overflow in my application, and I think one of the contributing factors might be tokio's stack usage. Similarly to #2055, I think I see that creating a task throught the unowned function goes through several layers of functions, each consuming creating a copy of the task on the stack before finally allocating it. The function sequence is as follows:

• task::unowned
• task::new_task
• RawTask::new
• Cell::new
• UnsafeCell::new

As in #2055, my code runs fine when i compile with --release, but gets a stack overflow in the code above otherwise. I am not very familiar with assembly, so I could be completely wrong in thinking that the callstack above leads to a lot of duplication of the stack-allocated task data, and I'm also not sure how feasible it would be to optimize this, so feel free to close if this is not something you can address. For now, I will just try to reserve more stack space.

[Darksonn]

We already have some code for spawned tasks to avoid this here:

tokio/tokio/src/task/spawn.rs

Lines 130 to 136 in 84c4a6d

	// preventing stack overflows on debug mode, by quickly sending the
	// task to the heap.
	if cfg!(debug_assertions) && std::mem::size_of::<T>() > 2048 {
	spawn_inner(Box::pin(future), None)
	} else {
	spawn_inner(future, None)
	}

However if you are using task::unowned, then you must be using spawn_blocking, in which case you don't hit the above piece of code. We could add the same to spawn_blocking.

[sander2]

We already have some code for spawned tasks to avoid this here:

tokio/tokio/src/task/spawn.rs

Lines 130 to 136 in 84c4a6d

	// preventing stack overflows on debug mode, by quickly sending the
	// task to the heap.
	if cfg!(debug_assertions) && std::mem::size_of::<T>() > 2048 {
	spawn_inner(Box::pin(future), None)
	} else {
	spawn_inner(future, None)
	}

However if you are using task::unowned, then you must be using spawn_blocking, in which case you don't hit the above piece of code. We could add the same to spawn_blocking.

Thanks for the quick reply, I made a PR to do just this

[Darksonn]

Closed by #4203.