c++ - boost::asio io_service 在 stop() 后不返回

Question

我正在开发一个应用程序，它使用 boost::asio 在不同端口上监听 TCP 和 UDP 数据包。我通过使用与 asio 教程示例中类似的服务器类来完成此操作，并将它们全部指向单个 io_service。

总的来说，我的主要功能(win32 控制台应用程序)如下所示:

int main(int argc, char* argv[])
{
    //some initializations here

    try
    {
        asio::io_service io_service;
        TcpServer ServerTCP_1(io_service, /*port number here*/);
        TcpServer ServerTCP_2(io_service, /*port number here*/);
        UdpServer ServerUDP(io_service, /*port number here*/);

        io_service.run();
    }
    catch(std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }

    //cleanup code here

    return 0;
}

我还通读了 HTTP 服务器示例，其中 signal_set 用于执行异步操作，该操作在退出信号进入时被激活(我也在服务器类中实现)。

这是我的 TcpServer 类:

class TcpServer : private noncopyable
{
public:
    TcpServer(asio::io_service& io_service, int port) : 
        acceptor_(io_service, tcp::endpoint(tcp::v4(), port)), 
        signals_(io_service), context_(asio::ssl::context::sslv3)
    {
        SSL_CTX_set_cipher_list(context_.native_handle(), "ALL");
        SSL_CTX_set_options(context_.native_handle(), SSL_OP_ALL);
        SSL_CTX_use_certificate_ASN1(context_.native_handle(), sizeof(SSL_CERT_X509), SSL_CERT_X509);
        SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, context_.native_handle(), SSL_CERT_RSA, sizeof(SSL_CERT_RSA));
        SSL_CTX_set_verify_depth(context_.native_handle(), 1);

        signals_.add(SIGINT);
        signals_.add(SIGTERM);
        signals_.add(SIGBREAK);
#if defined(SIGQUIT)
        signals_.add(SIGQUIT);
#endif // defined(SIGQUIT)
        signals_.async_wait(boost::bind(&TcpServer::handle_stop, this));

        start_accept();
    }

private:
    tcp::acceptor acceptor_;
    asio::ssl::context context_;
    asio::signal_set signals_;
    TcpConnection::pointer new_ssl_connection;

    void start_accept(){
        new_ssl_connection.reset(new TcpConnection(acceptor_.get_io_service(), context_));
        acceptor_.async_accept( new_ssl_connection->socket(), 
                                    boost::bind(&TcpServer::handle_acceptSSL, this, asio::placeholders::error));
    }

    void handle_acceptSSL(const system::error_code& error){
        if(!error)
            new_ssl_connection->start();
        start_accept();
    }
    void handle_stop(){
        acceptor_.close();
        printf("acceptor closed");
    }
};

现在因为我有 3 个不同的服务器对象，他应该关闭它们的所有接受器，让 io_service 不工作，这再次导致 io_service 从 运行返回() 调用应该使程序到达主函数中的清理代码，对吗？除此之外，printf 调用也应该执行 3 次，或者？

首先 io_service 没有返回，清理代码永远不会到达。其次，控制台中最多只显示一个 printf 调用。

第三，通过调试，我发现当我退出程序时，handle_stop() 被调用了一次，但由于某种原因，程序在句柄中的某处关闭(这意味着有时他进入 printf 并在那之后关闭，有时他只是进入 acceptor_.close())

另一件可能值得一提的事情是程序在关闭后不返回 0 而是返回这个(线程数不同):

The thread 'Win32 Thread' (0x1758) has exited with code 2 (0x2).
The thread 'Win32 Thread' (0x17e8) has exited with code -1073741510 (0xc000013a).
The thread 'Win32 Thread' (0x1034) has exited with code -1073741510 (0xc000013a).
The program '[5924] Server.exe: Native' has exited with code -1073741510 (0xc000013a).

所以我想知道为什么会这样，我该如何解决它以及如何正确获取清理代码？

Answer 1

io_service 永远不会返回，因为 io_service 中始终有工作。当acceptor::close()被调用时，acceptor 的异步接受操作将被立即取消。这些取消操作的处理程序将传递给 boost::asio::error::operation_aborted 错误。

在当前代码中，问题是新的异步接受操作总是被启动的结果，即使 acceptor 已经关闭。因此，工作总是被添加到 io_service。

void start_accept(){
  // If the acceptor is closed, handle_accept will be ready to run with an
  // error.
  acceptor_.async_accept(...,  handle_accept);
}

void handle_accept(const system::error_code& error){
  if(!error)
  {
    connection->start();
  }

  // Always starts a new async accept operation, even if the acceptor
  // has closed.
  start_accept();
}
void handle_stop(){
  acceptor_.close();
}

Boost.Asio 示例防止这种情况发生，检查 acceptor_ 是否已在 handle_accept 调用中关闭。如果 acceptor_ 不再打开，则处理程序会提早返回，而不会向 io_service 添加更多工作。

这是来自 HTTP Server 1 的相关片段示例:

void server::handle_accept(const boost::system::error_code& e)
{
  // Check whether the server was stopped by a signal before this completion
  // handler had a chance to run.
  if (!acceptor_.is_open())
  {
    return;
  }

  if (!e)
  {
    connection_manager_.start(new_connection_);
  }

  start_accept();
}