feat: add thread_stack_size params to customize the thread stack si…#3885
Closed
ZenasSong wants to merge 2 commits into
Closed
feat: add thread_stack_size params to customize the thread stack si…#3885ZenasSong wants to merge 2 commits into
thread_stack_size params to customize the thread stack si…#3885ZenasSong wants to merge 2 commits into
Conversation
…ze for SqliteConnectionPool
abonander
requested changes
Jun 28, 2025
| // Soft limit on the number of rows that `ANALYZE` touches per index. | ||
| pragmas.insert("analysis_limit".into(), None); | ||
|
|
||
| let default_thread_stack_size = 512 * 1024; // 512KB |
Collaborator
There was a problem hiding this comment.
I'm not comfortable making the default stack size this small. Because we invoke user-supplied callbacks from the worker thread, it's impossible to say what a safe minimum stack size is besides the current default.
Additionally, there's no leeway for platform-specific requirements. 64-bit platforms are going to need more stack size than 32-bit platforms because the size of pointers and usize/isize values is doubled.
This should be Option<usize> and default to not specifying a stack size and just letting the std choose.
Author
There was a problem hiding this comment.
Agree with you, I'll post a new PR!
Collaborator
|
Closing due to inactivity and unaddressed feedback. Feel free to open a new PR after addressing the comment. |
ZenasSong
added a commit
to ZenasSong/sqlx
that referenced
this pull request
Nov 1, 2025
Changes `thread_stack_size` from `usize` to `Option<usize>` to address concerns about safety and platform compatibility. Key improvements: - Default to `None`, using Rust std's default stack size (typically 2MB) - Only apply custom stack size when explicitly configured - Safer for user callbacks with unpredictable stack requirements - Platform-agnostic (handles 32-bit vs 64-bit differences automatically) - Marked as an advanced option in documentation with appropriate warnings This addresses the feedback from PR transact-rs#3885 about hardcoded stack sizes being unsafe due to: 1. Unpredictable stack needs of user-supplied callbacks 2. Platform-specific requirements (32-bit vs 64-bit) 3. Need for conservative defaults Related: transact-rs#3885
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The thread stack size could be critical on mobile devices. Adding the param
thread_stack_sizecould be more flexible, especially for building a mobile application.Does your PR solve an issue?
Delete this text and add "fixes #(issue number)".
Do not just list issue numbers here as they will not be automatically closed on merging this pull request unless prefixed with "fixes" or "closes".
Is this a breaking change?
Delete this text and answer yes/no and explain.
If yes, this pull request will need to wait for the next major release (
0.{x + 1}.0)Behavior changes can be breaking if significant enough.
Consider Hyrum's Law: