我正在运行一些需要异步通信的测试,底层框架是Asio.有时,即使测试已经被删除,处理程序也会保留在处理循环中,这是有充分理由的.但是,在删除目标后调用它.
测试类：
virtual void SetUp()
{
_client = new Client;
_server = new Server;
Service::run();
}
virtual void TearDown()
{
Service::stop();
delete _client;
delete _server;
}
服务类：
static void run()
{
_thread = new asio::thread(boost::bind(&asio::io_service::run, _service));
}
static void stop()
{
_service->stop();
_thread->join();
delete _thread;
_service->reset();
}
io_service :: stop()是非阻塞的,所以在我的情况下它变得毫无用处.如果我在函数末尾删除了io_service对象,则不会调用处理程序,但是我想要一个更好的解决方案,在删除对象之前强制完成.
注意：实际的处理循环是在第二个线程中完成的,但它是在io_service :: stop()包装器中连接的,整个问题似乎与线程无关.
我正在使用Asio(非Boost)1.4.5,但可以考虑升级(以获取io_service :: stopped()操作吗？).
编辑：根据评论添加io_service包装代码,因为它似乎是相关的.
解决方法:
在我看来,你需要稍微重新考虑你的设计.正如你所注意到的那样,io_service :: stop确实是异步的.它会导致io_service :: run()的任何调用尽快返回.在~io_service()析构函数运行之前,不会使用boost :: asio :: error :: operation_aborted调用任何未完成的处理程序.要管理对象生存期,您应该使用shared_ptr,如documentation所示：
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 function stop() is called
to terminate any run() calls as soon
as possible. The io_service destructor
defined above destroys all handlers,
causing all shared_ptr references to
all connection objects to be
destroyed.
更具体地说,你有一个竞争条件
virtual void TearDown()
{
service->stop();
// ok, io_service is no longer running
// what if outstanding handlers use _client or _server ??
delete _client;
delete _server;
// now you have undefined behavior due to a dangling pointer
}
标签：c,asynchronous,boost,boost-asio
来源： https://codeday.me/bug/20190730/1578891.html