Boost asio async_accept memory leak问题分析
来源:互联网 发布:华广软件套餐 编辑:程序博客网 时间:2024/06/05 02:24
可以看下stackflow上的问题描述:
Using boost::asio i use async_accept to accept connections. This works good, but there is one issue and i need a suggestion how to deal with it. Using typical 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)); }
Works fine but there is a issue: Request object is created with plain new so it can memory "leak". Not really a leak, it leaks only at program stop, but i want to make valgrind happy.
Sure there is an option: i can replace it with shared_ptr, and pass it to every event handler. This will work until program stop, when asio io_service is stopping, all objects will be destroyed and Requestwill be free'd. But this way i always must have an active asio event for Request, or it will be destroyed! I think its direct way to crash so i dont like this variant, too.
UPD Third variant: Listener
holds list of shared_ptr to active connections. Looks great and i prefer to use this unless some better way will be found. The drawback is: since this schema allows to do "garbage collection" on idle connects, its not safe: removing connection pointer from Listener will immediately destroy it, what can lead to segfault when some of connection's handler is active in other thread. Using mutex cant fix this cus in this case we must lock nearly anything.
Is there a way to make acceptor work with connection management some beautiful and safe way? I will be glad to hear any suggestions.
问题在于如果程序关掉,连接来了,new 出来的tcp::socket没有被释放。所以官方文档有讲到:
On destruction, the io_service
performs the following sequence of operations:
- For each service object
svc
in theio_service
set, in reverse order of the beginning of service object lifetime, performssvc->shutdown_service()
. - Uninvoked handler objects that were scheduled for deferred invocation on the
io_service
, or any associated strand, are destroyed. - For each service object
svc
in theio_service
set, in reverse order of the beginning of service object lifetime, performsdelete static_cast<io_service::service*>(svc)
.
Remarks
The destruction sequence described above permits programs to simplify their resource management by using shared_ptr<>
. Where an object's lifetime is tied to the lifetime of a connection (or some other sequence of asynchronous operations), a shared_ptr
to the object would be bound into the handlers for all asynchronous operations associated with it. This works as follows:
- When a single connection ends, all associated asynchronous operations complete. The corresponding handler objects are destroyed, and all
shared_ptr
references to the objects are destroyed. - To shut down the whole program, the
io_service
functionstop()
is called to terminate anyrun()
calls as soon as possible. Theio_service
destructor defined above destroys all handlers, causing allshared_ptr
references to all connection objects to be destroyed.
- Boost asio async_accept memory leak问题分析
- Memory Leak分析分享
- Memory Leak分析分享
- Memory Leak分析分享
- 解决memory leak问题
- 解决memory leak问题
- boost之asio分析
- boost::asio范例分析
- boost::asio范例分析
- boost asio 分析1
- 解决memory leak问题
- Boost::asio io_service 实现分析
- Boost::asio io_service 实现分析
- Boost::asio范例分析 客户端
- Boost::asio范例分析 服务端
- Boost::asio io_service 实现分析
- Boost::asio io_service 实现分析
- Boost::asio io_service 实现分析
- innobackupex参数说明
- 单例设计模式
- C#开发日志[2013-12-5]创建Bitmap引发"参数无效"异常
- Android 画图方式总结
- 回溯法:N后问题
- Boost asio async_accept memory leak问题分析
- android Intent匹配,自定义action data category
- struts 多语言配置
- (Java)判断回文串,忽略既非字母又非数字的字符
- WordPress中文标签伪静态设置方法,以及为什么出错?
- oracle实现对表dml错误记录日志
- 使用NSOperationQueue简化多线程开发
- 我妈要是知道这些,我早上北大了。
- ubuntu12.04 安装Gearman及其php扩展