Boost async_* functions and shared_ptr’s

by

In short, boost::bind creates a copy of the boost::shared_ptr<Connection> that is returned from shared_from_this(), and boost::asio may create a copy of the handler. The copy of the handler will remain alive until one of the following occurs:

  • The handler has been called by a thread from which the service’s run(), run_one(), poll() or poll_one() member function has been invoked.
  • The io_service is destroyed.
  • The io_service::service that owns the handler is shutdown via shutdown_service().

Here are the relevant excerpts from the documentation:

  • boost::bind documentation:

    The arguments that bind takes are copied and held internally by the returned function object.

  • boost::asio io_service::post:

    The io_service guarantees that the handler will only be called in a thread in which the run(), run_one(), poll() or poll_one() member functions is currently being invoked. […] The io_service will make a copy of the handler object as required.

  • boost::asio io_service::~io_service:

    Uninvoked handler objects that were scheduled for deferred invocation on the io_service, or any associated strand, are destroyed.

    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. […] 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.

While dated (2007), the Networking Library Proposal for TR2 (Revision 1) was derived from Boost.Asio. Section 5.3.2.7. Requirements on asynchronous operations provides some details for the arguments to async_ functions:

In this clause, an asynchronous operation is initiated by a function that is named with the prefix async_. These functions shall be known as initiating functions. […] The library implementation may make copies of the handler argument, and
the original handler argument and all copies are interchangeable.

The lifetime of arguments to initiating functions shall be treated as follows:

  • If the parameter is declared as a const reference or by-value […] the implementation may make copies of the argument, and all copies shall be destroyed no later than immediately after invocation of the handler.

[…] Any calls made by the library implementation to functions associated with the initiating function’s arguments will be performed such that calls occur in a sequence call1 to calln, where for all i, 1 ≤ i < n, calli precedes call i+1.

Thus:

  • The implementation may create a copy of the handler. In the example, the copied handler will create a copy of the shared_ptr<Connection>, increasing the reference count of the Connection instance while the copies of handler remain alive.
  • The implementation may destroy the handler prior to invoking handler. This occurs if the async operation is outstanding when io_serive::service is shutdown or the io_service is destroyed. In the example, the copies of handler will be destroyed, decreasing the reference count of Connection, and potentially causing the Connection instance to be destroyed.
  • If handler is invoked, then all copies of handler will immediately be destroyed once execution returns from the handler. Again, the copies of handler will be destroyed, decreasing the reference count of Connection, and potentially causing it to be destroyed.
  • The functions associated with the asnyc_‘s arguments, will be executed sequentially, and not concurrent. This includes io_handler_deallocate and io_handler_invoke. This guarantees that the handler will not be deallocated while the handler is being invoked. In most areas of the boost::asio implementation, the handler is copied or moved to stack variables, allowing the destruction to occur once execution exits the block in which it was declared. In the example, this ensures that the reference count for Connection will be at least one during the invocation of the handler.

More Related Contents:

  1. Why do I need strand per connection when using boost::asio?
  2. What is the usefulness of `enable_shared_from_this`?
  3. How to create a thread pool using boost in C++?
  4. Should the exception thrown by boost::asio::io_service::run() be caught?
  5. Should we pass a shared_ptr by reference or by value?
  6. Best documentation for Boost:asio?
  7. How to set a timeout on blocking sockets in boost asio?
  8. C++ – passing references to std::shared_ptr or boost::shared_ptr
  9. boost asio ssl async_shutdown always finishes with an error?
  10. How to avoid memory leak with shared_ptr?
  11. Cancelling boost asio deadline timer safely
  12. How to release pointer from boost::shared_ptr?
  13. Boost ASIO streambuf
  14. Where is shared_ptr?
  15. Copy a streambuf’s contents to a string
  16. Boost::asio – how to interrupt a blocked tcp server thread?
  17. Detach a pointer from a shared_ptr? [duplicate]
  18. Is boost shared_ptr thread safe?
  19. shared_from_this causing bad_weak_ptr
  20. C++ Boost ASIO simple periodic timer?
  21. When must you pass io_context to boost::asio::spawn? (C++)
  22. BOOST ASIO – How to write console server
  23. Example to use shared_ptr?
  24. Using shared_ptr in dll-interfaces
  25. Exception running boost asio ssl example
  26. Boost.Asio as header-only
  27. asio How to change the executor inside an awaitable?
  28. Strange exception throw – assign: Operation not permitted
  29. Why does Boost.Asio not support an event-based interface?
  30. Conversion from boost::shared_ptr to std::shared_ptr?

Leave a Comment