使用boost :: asio我使用async_accept接受连接。这很好,但有一个问题,我需要一个如何处理它的建议。使用典型的async_accept:
Listener::Listener(int port)
: acceptor(io, ip::tcp::endpoint(ip::tcp::v4(), port))
, socket(io) {
start_accept();
}
void Listener::start_accept() {
Request *r = new Request(io);
acceptor.async_accept(r->socket(),
boost::bind(&Listener::handle_accept, this, r, placeholders::error));
}
工作正常但存在问题:请求对象是使用普通的新创建的,因此它可以记忆“泄漏”。不是真的泄漏,它只在程序停止时泄漏,但我想让 valgrind 高兴。
当然有一个选项:我可以用 shared_ptr 替换它,并将其传递给每个事件处理程序。这将一直有效,直到程序停止,当asio io_service 停止时,所有对象都将被销毁,请求将被释放。但是这样我总是必须为请求设置一个活跃的asio事件,否则它将被销毁!我认为它是崩溃的直接方式所以我也不喜欢这种变体。
UPD第三种变体:Listener
包含shared_ptr到活动连接的列表。看起来很棒,我更喜欢使用它,除非找到更好的方法。缺点是:由于此模式允许在空闲连接上执行“垃圾收集”,因此不安全:从侦听器中删除连接指针将立即销毁它,当某些连接的处理程序在其他线程中处于活动状态时,会导致段错误。在这种情况下,使用互斥锁无法修复此cus,我们必须锁定几乎任何东西。
有没有办法让 acceptor 使用连接管理一些美观和安全的方式?我很乐意听到任何建议。
答案 0 :(得分:2)
使用此库时避免内存泄漏的典型方法是使用shared_ptr
,io_service
documentation专门提及此
说明
上述破坏序列允许程序简化 使用
shared_ptr<>
进行资源管理。对象的位置 生命周期与连接的生命周期(或其他一些因素)有关 异步操作序列),对象的shared_pt
r 绑定到所有相关的异步操作的处理程序 用它。其工作原理如下:当单个连接结束时,所有关联的异步操作 完成。相应的处理程序对象将被销毁 对对象的shared_ptr引用被销毁。关闭了 整个程序,调用
io_service
函数stop()
来终止 尽快拨打任何run()
电话。 io_service析构函数已定义 上面会破坏所有处理程序,导致所有shared_ptr
引用 要销毁的连接对象。
针对您的方案,更改Listener::handle_accept(
)方法以获取boost::shared_ptr<Request>
参数。你的第二个问题
通过继承类中的从Listener中删除连接指针会立即将其破坏, 当一些连接的处理程序处于活动状态时,什么可能导致段错误 在其他线程中。在这种情况下,我们必须使用互斥锁来解决这个问题 几乎锁定任何东西。
boost::enable_shared_from_this
模板来缓解:
class Listener : public boost::enable_shared_from_this<Listener>
{
...
};
然后在分派处理程序时,在绑定到shared_from_this()
的成员函数时使用this
而不是Listener
。
答案 1 :(得分:0)
如果有人感兴趣,我找到了另一种方式。 Listener
保存shared_ptr到活动连接的列表。终止/终止的连接是通过io_service::post
进行的,Listener::FinishConnection
调用asio::strand
。通常我总是使用strand包装Request的方法 - 它在DDOS和/或线程安全方面更安全。因此,使用FinishConnection
从post
调用strand
可以防止其他线程中的段错误
答案 2 :(得分:0)
不确定这是否与您的问题直接相关,但我也使用 Boost Asio 库,特别是您提到的同一个acceptor
对象,也有类似的内存泄漏。原来我没有正确关闭服务;某些连接将保持打开状态,并且不会从内存中释放相应的对象。调用以下内容可以消除 Valgrind 报告的泄漏:
acceptor.close();
希望这对某人有用!