Kevin Li

any suggestion?

https://github.com/apache/brpc/pull/2670 @lorinlee @chenBright ry to make one. is there some one could help to review it?

I just finish exporting some wait-free & malloc-free async logger practice used internal in baidu [[documented here](https://github.com/baidu/babylon/blob/main/docs/logging/index.md)]. Integrate these to LOG macro leaves a disaster of tricks internal. If there...

- To remove the front end copy, I need to replace the implementation of LogMessage.stream() - in glog sending to sink have some internal locks

Good enough for me. I have a similar design [here](https://github.com/baidu/babylon/blob/main/docs/logging/logger.md). A std::streambuf plugin point is easier to do the integration

1.11版本应该已经比较正式地支持bzlmod模式了，不过还有几个老deps还没有进bcr，目前要联合私服一起用

https://github.com/apache/brpc/blob/master/docs/cn/io.md https://github.com/apache/brpc/blob/master/docs/cn/execution_queue.md brpc里的MPSC一般都是这个套路实现的，比如上面这俩都是，braft应该也是广泛用了这个模式； 经典的双端链表队列实现是Michael&Scott的[non-blocking queue](https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf)，boost里有一个对应的实现boost::lock_free:queue，不过入队动作依赖CAS，CAS本身在竞争比较大的时候有自旋问题其实并发能力一般； brpc这个单端链表核心就是通过不会失败不会自旋的exchange替换CAS提升了并发能力；也因为是通过和当前队尾进行exchage动作来成为新的队尾，整体的单链指向就只能是队尾指向前序节点的逆序链表了； 不过单纯看性能，基于数组的队列一般比链表类队列整体吞吐要高一些；所以这种链表类队列主要的优势点还是在于大量队列（例如作为接入层server承接大链接数）时不用预留数组长度，内存有节省；但是大链接数一般单链接上竞争就不强了，其实哪怕mutex保护的单链其实问题都不大；而有大并发的场景，因为链接数规模可控，可能进一步上数组队列的并发能力会更好（比如直接iouring之类的）；甚至大链接数场景，按链接组做聚簇之后上数组队列可能均衡意义上有时也强过链表队列； 只看MPSC并发能力的话，比较久之前做过一个简易评测 producer=12 consumer=1 | qps | cpu | latency | qps | cpu | latency | qps | cpu | latency -- |...

目前消费动作应该也是用这个exchage摘除队尾的方式来做的。正向链消费感觉会有一些比较困难的点 1、需要再留一个虚拟头，消费从虚拟头发起，也给队尾侧提供一个起点 2、从虚拟头消费时候，不好确定终止点，遇到nullptr有可能是真的尾，也可能是正在准备链接的中间，需要读取当前尾部进行校验 3、要做按需启动消费的话，不能单纯像现在依赖交换结果来判断，需要加一些额外的计数机制联合使用 4、不过最麻烦的还是，正向接链表会导致，最后一个节点消费后，很难直接找到安全delete/recycle掉的时机（因为随时有可能有新的入队需要操作它的next, 逆向是不会有这种问题的）；那么就需要用虚拟头来交换尾节点，然后这个交换又可能交换到更新的插入者，还要再一次尝试跟随nullptr直到这个自己交换得到的尾部； 初步这么理了下，感觉好像不是不能做，不过实现复杂度提升不少