關於創建boost.asio async_xxxx處理程序對象

Question

我正在閱讀Boost.Asio源代碼，但存在我感到困惑的代碼。有沒有人幫助解釋爲更好的理解，或一些材料，我可以參考理解？謝謝。

的實際代碼：

// Wait until data can be received without blocking. 
    template <typename Handler> 
    void async_receive_from(implementation_type& impl, 
     const null_buffers&, endpoint_type& sender_endpoint, 
     socket_base::message_flags flags, Handler& handler) 
    { 
    bool is_continuation = 
     boost_asio_handler_cont_helpers::is_continuation(handler); 

    // Allocate and construct an operation to wrap the handler. 
    typedef reactive_null_buffers_op<Handler> op; 
    typename op::ptr p = { boost::asio::detail::addressof(handler), 
     boost_asio_handler_alloc_helpers::allocate(
     sizeof(op), handler), 0 }; 
    p.p = new (p.v) op(handler); 

    BOOST_ASIO_HANDLER_CREATION((p.p, "socket", 
      &impl, "async_receive_from(null_buffers)")); 

    // Reset endpoint since it can be given no sensible value at this time. 
    sender_endpoint = endpoint_type(); 

    start_op(impl, 
     (flags & socket_base::message_out_of_band) 
      ? reactor::except_op : reactor::read_op, 
     p.p, is_continuation, false, false); 
    p.v = p.p = 0; 
    } 

尤其是對：

typedef reactive_null_buffers_op<Handler> op; 
typename op::ptr p = { boost::asio::detail::addressof(handler), 
    boost_asio_handler_alloc_helpers::allocate(
    sizeof(op), handler), 0 }; 
p.p = new (p.v) op(handler); 

感謝。

Answer 1

嗯..請參閱...您試圖瞭解reactive_socket_service類的功能async_receive_from。具體來說，需要null_buffer。

功能的簽名：

template <typename Handler> 
    void async_receive_from(implementation_type& impl, 
          const null_buffers&, 
          endpoint_type& sender_endpoint, 
          socket_base::message_flags flags, 
          Handler& handler) 

現在，什麼是null_buffers的重要性？

簡而言之，它基本上允許在被調用的回調中執行緩衝區管理，而不是在提供緩衝區時調用async_receive_from，就像在其他過載中一樣。
有關其用例的更詳細說明，請參閱THIS答案。

什麼是reactive_null_buffers_op<Handler> op？

既然你是在這一點上，我假設你知道在asio中的operation類。簡而言之，當特定操作完全執行時，它基本上會調用用戶提供的回調函數。請在scheduler_operation.hpp中查找scheduler_operation::complete。

reactive_null_buffers_op源自scheduler_operation（通過reactive_op）並且它還存儲傳遞給async_receive_from的處理程序的副本。實際的細節有點複雜和有用。現在知道這個類的do_complete方法就是處理程序的上調可能就足夠了。

什麼是typename op::ptr？

尋找ASIO_DEFINE_HANDLER_PTR在handler_alloc_helpers.hpp。簡而言之，它是一個持有傳遞給異步函數的處理程序的結構。 ASIO需要在堆（或通過自定義分配器）上分別分配處理程序，以確保其在套接字接收操作完成期間存在。這是下面兩行有哪些呢：

typename op::ptr p = { boost::asio::detail::addressof(handler), 
     boost_asio_handler_alloc_helpers::allocate(
     sizeof(op), handler), 0 }; 
    p.p = new (p.v) op(handler); 

我們通過placement new（2號線）創建的reactive_null_buffers_op<Handler>的分配空間的實例。

現在呢？

一個ASIO存儲了用戶傳遞的處理程序對象，它需要在套接字上啓動主要的讀取操作。爲此，它調用start_op函數。 start_op的詳細信息超出了問題的當前範圍。因此，簡而言之，start_op最終註冊到輪詢器的套接字，例如epoll。我們的處理程序，現在在op，當讀取操作準備好執行時，最終會被調用（跳過了大量的細節）。