Boost asio async_accept memory leak问题分析
2013-12-05 11:14
627 查看
可以看下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:
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:
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
the following sequence of operations:
For each service object
in reverse order of the beginning of service object lifetime, performs
Uninvoked handler objects that were scheduled for deferred invocation on the
or any associated strand, are destroyed.
For each service object
in reverse order of the beginning of service object lifetime, performs
Remarks
The destruction sequence described above permits programs to simplify their resource management by using
Where an object's lifetime is tied to the lifetime of a connection (or some other sequence of asynchronous operations), a
with it. This works as follows:
When a single connection ends, all associated asynchronous operations complete. The corresponding handler objects are destroyed, and all
the objects are destroyed.
To shut down the whole program, the
called to terminate any
defined above destroys all handlers, causing all
提倡用智能指针。其实可以嘛。
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:
Listenerholds
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_serviceperforms
the following sequence of operations:
For each service object
svcin the
io_serviceset,
in reverse order of the beginning of service object lifetime, performs
svc->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
svcin the
io_serviceset,
in reverse order of the beginning of service object lifetime, performs
delete 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_ptrto 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_ptrreferences to
the objects are destroyed.
To shut down the whole program, the
io_servicefunction
stop()is
called to terminate any
run()calls as soon as possible. The
io_servicedestructor
defined above destroys all handlers, causing all
shared_ptrreferences to all connection objects to be destroyed.
提倡用智能指针。其实可以嘛。
相关文章推荐
- VC调试boost::asio::async_send_to时候的一个问题(_Debug_message assert的异常)
- boost::asio范例分析
- “Form_Load时添加的AsyncPostBackTrigger失效”问题分析及解决方案
- Boost::asio io_service 实现分析
- Boost::asio io_service 实现分析
- boost asio 几个问题
- 【Boost】boost库asio详解2——io_service::run函数无任务时退出的问题
- boost::asio async_write也不能保证一次发完所有数据 一
- 关于BOOST的ASIO库的Socket最大连接数问题
- Boost::asio io_service 实现分析
- aio,epoll,libevent,boost::asio解决的问题
- boost asio io_service与 strand 分析
- 并发编程(二):分析Boost对 互斥量和条件变量的封装及实现生产者消费者问题
- Boost::asio范例分析 服务端
- BOOST::ASIO多线程下socket关闭导致进程崩溃问题定位及解决
- Boost::asio io_service 实现分析
- 并发编程(二):分析Boost对 互斥量和条件变量的封装及实现生产者消费者问题
- boost之asio分析
- asyframe - 基于Boost.asio的半同步/半异步(Half-Sync/Half-Async)通信框架 - Google Project Hosting
- boost::asio async_write也不能保证一次发完所有数据 一