feng-y opened a new pull request, #3309: URL: https://github.com/apache/brpc/pull/3309
## Problem In `SendRpcResponse`, `ConcurrencyRemover` was destroyed before `CallAfterRpcResp` was called. This means the concurrency control didn't cover the after-response callback, which could lead to: - Inaccurate concurrency tracking - Incorrect latency measurements - Premature resource release if callbacks hold resources ## Solution Add `FLAGS_concurrency_remover_manages_after_rpc_resp` (default: `false`) to optionally extend `ConcurrencyRemover`'s lifetime to cover `CallAfterRpcResp`. ### Behavior - **flag=false (default)**: Original behavior - `ConcurrencyRemover` is released before `CallAfterRpcResp` via explicit `reset()` - **flag=true**: `ConcurrencyRemover` lives until the end of `BRPC_SCOPE_EXIT`, covering the entire response lifecycle including after-response callbacks ### Implementation Uses `unique_ptr` with explicit `reset()` for clear control flow: - Always allocate `ConcurrencyRemover` via `unique_ptr` - Default path: explicitly `reset()` before `CallAfterRpcResp` - Extended path: let `unique_ptr` naturally destruct at scope end ## Backward Compatibility ✅ Default behavior unchanged (flag defaults to `false`) ✅ No impact on existing deployments ✅ Opt-in feature for users who need accurate concurrency tracking ## Testing Tested with: - Default flag value (original behavior preserved) - Flag enabled (concurrency properly managed through `CallAfterRpcResp`) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
