关于 RPCBuffer::cut 和 BRPC 中的 attachment 使用的问题

[zhang275]

假设原缓存块为 B，切分后的新缓存块为 B1，B2；如果切分位置正好位于某个缓存块 M1 的中间部分，那么 M1 将由 B1、B2 共同使用，但归 B1 管理其内存，其中在 B1 中 M1 类型为 BUFFER_MODE_GIFT_MALLOC，B2 中为 BUFFER_MODE_NOCOPY；

此时，cut 函数隐含的条件为 B1 中 M1 缓存块不能先于 B2 释放；

然而，我注意到在 BRPCRequest::deserialize_meta 中调用了 cut 函数，将 message 拆分为 message 和 attachment；

假设在服务器端并没有改变 attachment （是否必须在服务器端调用 get_attachment_nocopy 函数，以避免下面的问题？）

最后返回响应时，在 BRPCMessage::encode 中会先调用 message->encode，再调用 attachment->encode，在 RPCBuffer::encode 中会采用两两合并缓存块的方式，其中涉及到缓存的重新申请和复制，如果将 M1 缓存块释放，那么 attachment 是否收到影响， 这是否违背了这个隐含条件？

[holmes1412]

你好，感谢你的分析！不知道我对你的描述理解是否正确。但我感觉不会存在这个问题，原因在于框架的流程：

1. 服务器开始处理，构造了RPCServerTask，其中RPCRequest和RPCResponse都是它的成员，它们的生命周期持续到当前'处理'的任务流SeriesWork结束；
2. 框架开始按照BRPC协议收RPCRequest类，在你说的cut函数拿到了message和attachment；
3. 框架调用用户的处理函数比如Echo()，服务器要返回的内容和要回复的attachment会设置到RPCResponse上；
4. RPCResponse被调用encode()，按照BRPC协议告诉框架怎么发出；

由于会被encode的是服务器的Response，而收的时候被cut的是Request，是两个不一样的RPCMessage，所以不会有你所说的问题。

不过你说的隐含条件是对的，使用上确实需要非常小心。也许应该对RPCBuffer做一些其他机制尽量避免用错。非常欢迎提出更多讨论和建议！

[zhang275]

感谢您的回答，确实混淆了 RPCRequest 和 RPCResponse。