[PR] Use object_pool to store keytable by gflag (brpc)

2024-05-19 Thread via GitHub
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,未删除

Re: [PR] enable aligned new if supported (brpc)

2024-05-19 Thread via GitHub
ehds commented on PR #2421: URL: https://github.com/apache/brpc/pull/2421#issuecomment-2119135643 > 是这么理解吧 是的。如果用户使用 brpc 提供的默认 CMakeLists 来编译安装,但是在项目中又开启了该参数就会引发这个问题,两者要保持。 我的理解是:既然某些类显示的标注了 CacheLine 对齐,那么如果编译器支持,那么尽量就是用对齐的分配方式,来达到 CacheLine 对齐所带来的益处。 -- This is an aut

Re: [PR] enable aligned new if supported (brpc)

2024-05-19 Thread via GitHub
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

Re: [PR] Use object_pool to store keytable by gflag (brpc)

2024-05-19 Thread via GitHub
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

Re: [PR] Use object_pool to store keytable by gflag (brpc)

2024-05-19 Thread via GitHub
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