-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix(engine): adjust thread pool size calculation for FeatureCityGmlReader #899
Conversation
Warning Rate limit exceeded@miseyu has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 17 minutes and 40 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request modifies the thread pool calculation in the Changes
Possibly related PRs
Poem
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
|
✅ Deploy Preview for reearth-flow canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
engine/runtime/action-processor/src/feature/reader/citygml/processor.rs (1)
128-130
:⚠️ Potential issueFix inconsistency in thread count reporting.
The
num_threads()
method returns 2, which is inconsistent with the actual thread pool size calculation that uses a maximum of 4 threads.Update the method to return the actual thread count:
- fn num_threads(&self) -> usize { - 2 - } + fn num_threads(&self) -> usize { + self.thread_pool.lock().current_num_threads() + }
🧹 Nitpick comments (2)
engine/runtime/action-processor/src/feature/reader/citygml/processor.rs (2)
83-89
: Consider making thread pool size configurable.While reducing the thread count can help avoid contention, hardcoding the divisor (4) and maximum threads (4) might not be optimal for all workloads and hardware configurations.
Consider making these values configurable through the
FeatureCityGmlReaderParam
:pub struct FeatureCityGmlReaderParam { dataset: Expr, flatten: Option<bool>, + thread_divisor: Option<f32>, + max_threads: Option<usize>, }Then update the thread calculation to use these parameters with fallback to defaults:
let thread_divisor = params.thread_divisor.unwrap_or(4.0); let max_threads = params.max_threads.unwrap_or(4); let size = (num_cpus::get() as f32 / thread_divisor).trunc() as usize; let threads_num = if size < 1 { 1 } else { std::cmp::min(size, max_threads) };
143-159
: Improve thread pool management.The current implementation could benefit from better thread pool management:
- Consider implementing graceful shutdown
- Add task cancellation support for long-running operations
Consider implementing a cancellation mechanism using
tokio::sync::CancellationToken
:use tokio::sync::CancellationToken; // Add to struct pub struct FeatureCityGmlReader { // ... cancellation_token: CancellationToken, } // Update process method fn process(&mut self, ctx: ExecutorContext, fw: &ProcessorChannelForwarder) -> Result<(), BoxedError> { let token = self.cancellation_token.child_token(); let fw = fw.clone(); // ... pool.spawn(move || { if token.is_cancelled() { return; } // ... rest of the processing }); Ok(()) } // Update finish method to cancel tasks before timeout fn finish(&self, ctx: NodeContext, _fw: &ProcessorChannelForwarder) -> Result<(), BoxedError> { self.cancellation_token.cancel(); // ... rest of the finish logic }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
engine/runtime/action-processor/src/feature/reader/citygml/processor.rs
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: ci-engine / ci
Overview
What I've done
What I haven't done
How I tested
Screenshot
Which point I want you to review particularly
Memo
Summary by CodeRabbit
Refactor
Chores
engine
package from "0.0.15" to "0.0.16".plateau-gis-quality-checker
package from "0.0.12" to "0.0.13".