Yang,Liming

> > attachment，在接收端，你希望直接用显存来接收吗？ > > 是的，attachment其实就是训练过程所需要的一些数据，因此我们希望直接从一台机器的显存传输到另一台机器的显存上。 现在brpc协议，meta部分的长度不固定，感觉不太好搞，这种我觉得自定义一个协议会比较好，比如： 1、头部长度在消息里面，可以直接截取消息头。 2、剩下的是attachment可以直接申请显存的内存，接收消息。

一般是性能跟不上了，去增加线程数量。减少线程的需求不是很多。而且内部实现，减少会把已有的很多已经初始化的worker相关东西都要析构掉，这块实现上比较复杂。

I believe the long-term solution is to have users register memory with RDMA, allowing users to customize this memory based on their data organization methods. https://zhuanlan.zhihu.com/p/376989325 This link contains some...

If the request is submitted to the local io_uring function in pthread1, this bthread may be scheduled to pthread2 later. In this case, pthread1 still needs to reap the corresponding...

I believe you're trying to create a run-to-complete model. In a bRPC scenario, the easiest ways to implement this model seem to be: 1. Using RDMA's polling mode 2. Modifying...

What I mean is that in the io_uring scenario, if polling mode is not applicable, eventfd can be used to register io_uring events with epoll. I think the efficiency problem...

Yes, I know you want a mechanism to harvest asynchronous responses, and this PR https://github.com/apache/brpc/pull/2560 is actually designed to support this scenario. It doesn't require modifying the bthread scheduling strategy.

When the first follower responds, the parent span is prematurely destroyed along with all child spans Because you just need to wait the first response?

maybe we can add a reference counter in span, There may be much less code modification.

Root Cause: a. Premature deallocation: Parent span destroyed while child spans still in use b. Dangling pointer: Response callback accesses freed span objects The span information is a tree structure,...