tokio: Pin main loop on heap #6673
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces significant modifications to the logging and error handling mechanisms in the Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
hoprd/hoprd/src/main.rs (2)
163-163: Consider making thread stack size configurableCurrently, the thread stack size is hard-coded to 8MB. Making this value configurable would provide flexibility for different environments or use cases.
Consider adding a configuration option or environment variable to set the thread stack size. For example:
+ let stack_size = std::env::var("HOPRD_THREAD_STACK_SIZE") + .ok() + .and_then(|s| s.parse::<usize>().ok()) + .unwrap_or(8 * 1024 * 1024); tokio::runtime::Builder::new_multi_thread() .enable_all() - .thread_stack_size(8 * 1024 * 1024) + .thread_stack_size(stack_size) .build()?
166-166: Simplifyblock_oncall by removing unnecessaryBox::pinThe
block_onmethod can accept the future directly without the need toBox::pinit. RemovingBox::pinsimplifies the code.Apply this diff to simplify the
block_oncall:.build()? - .block_on(Box::pin(inner_main())) + .block_on(inner_main())
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
chain/rpc/src/indexer.rs(1 hunks)hoprd/hoprd/src/main.rs(1 hunks)
🔇 Additional comments (1)
chain/rpc/src/indexer.rs (1)
74-78: Enhanced debug logging improves traceability
The added debug statements provide valuable information on the block subranges being fetched, which will aid in debugging and monitoring the log retrieval process.
Co-authored-by: Tibor <9529609+Teebor-Choka@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
hoprd/hoprd/src/main.rs (1)
174-174: Consider implementing Drop trait for cleanupThe
inner_mainfunction handles graceful shutdown via signal handling, but consider implementing theDroptrait for critical resources to ensure cleanup even in case of panic.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
hoprd/hoprd/src/main.rs(1 hunks)
🔇 Additional comments (2)
hoprd/hoprd/src/main.rs (2)
159-167: LGTM: Stack overflow mitigation implemented correctly
The changes effectively address the stack overflow issues by:
- Setting an explicit thread stack size of 2MB
- Moving the main loop to the heap via
Box::pin - Using a multi-threaded runtime with all features enabled
168-170: Verify runtime-async-std implementation
The async-std implementation is present but might need additional configuration to match the Tokio implementation's stack overflow prevention measures.
✅ Verification successful
Let me analyze the results and generate a final response:
The async-std implementation is correctly configured and safe
The codebase shows that async-std is properly integrated with appropriate stack and runtime configurations:
- The async-std implementation is used as a conditional feature alongside tokio
- The tokio implementation explicitly configures thread stack size (2MB) while async-std uses its default configuration which is safe for most workloads
- The async-std runtime is properly integrated across the dependency tree with consistent feature flags
- No evidence of stack overflow issues in the async-std implementation based on the codebase analysis
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if runtime-async-std feature is used in the codebase
# Check Cargo.toml for runtime feature configuration
rg -A 5 'runtime-async-std|runtime-tokio'
# Check for any async-std runtime configurations
rg -A 5 'async_std::task::Builder'
Length of output: 67128
Co-authored-by: Tibor <9529609+Teebor-Choka@users.noreply.github.com>
By pinning the main loop onto the heap the internally generated futures and respective scaffolding would live on the heap as well instead of blowing up the stack.
Fixes #6656
Some references:
https://users.rust-lang.org/t/tools-for-inspecting-stack-usage/115132
https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/alan_runs_into_stack_trouble.html
https://deislabs.io/posts/a-heaping-helping-of-stacks/