MJY-HUST opened a new pull request, #2645:
URL: https://github.com/apache/brpc/pull/2645
### What problem does this PR solve?
Issue Number:
#2635
Problem Summary:
如issue讨论,使用object_pool来管理KeyTable,避免如使用bthread_keytable_pool_t管理时出现的锁的竞争。此PR是一个初步实现,通过gflags控制是否使用object_pool,未删除
ehds commented on PR #2421:
URL: https://github.com/apache/brpc/pull/2421#issuecomment-2119135643
> 是这么理解吧
是的。如果用户使用 brpc 提供的默认 CMakeLists 来编译安装,但是在项目中又开启了该参数就会引发这个问题,两者要保持。
我的理解是:既然某些类显示的标注了 CacheLine 对齐,那么如果编译器支持,那么尽量就是用对齐的分配方式,来达到 CacheLine
对齐所带来的益处。
--
This is an aut
yanglimingcn commented on PR #2421:
URL: https://github.com/apache/brpc/pull/2421#issuecomment-2119166722
brpc的默认行为和编译器的默认行为保持一致这样是不是不容易产生问题。
一个用户如果对brpc的编译和对自己程序的编译选项不一致,他本身得认识到这个问题。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on t
chenBright commented on PR #2645:
URL: https://github.com/apache/brpc/pull/2645#issuecomment-2119556697
object_pool应该没法完全解决 #1449
的问题吧,从object_pool取出来的KeyTable有可能已经有data了,先调用bthread_setspecific函数,旧data还是会泄漏。
--
This is an automated message from the Apache Git Service.
To respond to the me
chenBright commented on PR #2645:
URL: https://github.com/apache/brpc/pull/2645#issuecomment-2119559198
https://github.com/apache/brpc/blob/b601c89aec9042a1f509ddbdad478aa4e3f118fe/src/brpc/server.h#L170-L183
https://github.com/apache/brpc/blob/b601c89aec9042a1f509ddbdad478aa4e3f118fe/sr