Skip to content

Adjust spawn_blocking() queue resize check#8046

Open
Darksonn wants to merge 1 commit intotokio-rs:masterfrom
Darksonn:buffer-resize-even-if-not-full
Open

Adjust spawn_blocking() queue resize check#8046
Darksonn wants to merge 1 commit intotokio-rs:masterfrom
Darksonn:buffer-resize-even-if-not-full

Conversation

@Darksonn
Copy link
Copy Markdown
Member

Let's avoid wasting work on allocating a larger buffer many times just because a single item was popped while the lock was not held.

cc @alex

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-blocking Module: tokio/task/blocking labels Apr 15, 2026
@github-actions github-actions Bot added the R-loom-blocking Run loom `runtime::spawn_blocking` tests on this PR label Apr 15, 2026
@alex
Copy link
Copy Markdown
Contributor

alex commented Apr 15, 2026

Seems was reasonable. Was this found with profiling a real workload or just reviewing the code?

@Darksonn
Copy link
Copy Markdown
Member Author

Just reviewing the code.

@afurm
Copy link
Copy Markdown

afurm commented Apr 15, 2026

The new condition new_queue.capacity() > queue.capacity() triggers a resize even when the queue isn't full. If the original queue had room but new_queue was overallocated (e.g., from a prior shrink_to_fit), this allocates a larger buffer unnecessarily. Is that trade-off intentional given the comment about not wasting the allocation?

@Darksonn
Copy link
Copy Markdown
Member Author

I don't think we ever call shrink_to_fit() on the queue to begin with.

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-blocking Module: tokio/task/blocking R-loom-blocking Run loom `runtime::spawn_blocking` tests on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants