CODEWITHSUNDEEP
c++socketsboostboost-asioshared-ptr
Toby
Toby

Reputation: 3905

Boost Asio - handling resolver and sockets with shared_ptr

I have a class which shall be capable of dispatching messages over TCP. Here the simplified interface:

class CommandScreenshot : public CameraCommand
{
public:
    CommandScreenshot();
    ~CommandScreenshot();
    void Dispatch(boost::shared_ptr<boost::asio::io_service> io_service);

 private:
     void resolve_handler(const boost::system::error_code& err,
          boost::asio::ip::tcp::resolver::iterator endpoint_iterator);

};

As you can see I have a function Dispatch, which actually just has the purpose of starting the async operation:

void CommandScreenshot::Dispatch(boost::shared_ptr<boost::asio::io_service> io_service)
{
    boost::asio::ip::tcp::resolver resolver(*io_service);
    boost::asio::ip::tcp::resolver::query query(m_hostname,"http");
    resolver.async_resolve(query,boost::bind(&CommandScreenshot::resolve_handler,this,boost::asio::placeholders::error, boost::asio::placeholders::iterator));
    return;
}

Everything else will be done in the following callback functions. The io_serviceobject, as well as the corresponding thread are managed by another class ( which has an instance of CommandScreenshot and calls the Dispatch function ).

Now to implement a simple TCP connection with Boost you need a resolver and a socket object, both bound to the io_service object. Since the io_service object will be only passed at the time, the function is called, I cant initialize them in the class constructor. Also it is not possible to declare them as class members and then just initialize them in the function itself.

My first idea was to just initialize them at function call and pass them to my completion handler. That would mean i declare both objects everytime the function is called and bind them to the io_service. Then at async_resolve, I add both as parameters via boost::bind. That would mean that my resolve_handler would expect more arguments - e.g.:

void resolve_handler(const boost::system::error_code& err,
          boost::asio::ip::tcp::resolver::iterator endpoint_iterator,
          boost::asio::ip::tcp::resolver resolver,
          boost::asio::ip::tcp::socket socket);

I actually doubt that this is a decent and fair solution. Usually those objects should kept as members and not be copied around - So I gave it another thought and my mind took me to the boost::shared_ptr.

In my header it looks now like this:

// Stuff above stays the same
private:
  boost::shared_ptr<boost::asio::ip::tcp::resolver> m_resolver;
  boost::shared_ptr<boost::asio::ip::tcp::socket> m_socket;
// Stuff below stays the same

And the implementation would be:

void CommandScreenshot::Dispatch(boost::shared_ptr<boost::asio::io_service> io_service)
{
    m_resolver.reset(new boost::asio::ip::tcp::resolver(*io_service));
    m_socket.reset(new boost::asio::ip::tcp::socket(*io_service));
    boost::asio::ip::tcp::resolver::query query(m_hostname,"http");
    m_resolver->async_resolve(query,boost::bind(&CommandScreenshot::resolve_handler,this,boost::asio::placeholders::error, boost::asio::placeholders::iterator));
    return;
}

With this, I don't need to copy around like 4 ( or maybe even more ) parameters and bind them together. When I need the socket object I can just access it via the pointer, which is a class member.

Now my simple question is -> is this the right way to go? The function can be called multiple times, even if the async part isn't finished. ( I'm aware that I should protect the socket and the resolver with a mutex then ). But is this clean, that I everytime create a new object when I call the Dispatch function? Is the reset call enough to get rid of any unneeded memory?

I know this is a long text for a particular short question and furthermore there isn't even an error tiself. But I always like to know if it's a decent way I am goin and if there is a better one, how I would do it.

Upvotes: 4

Views: 2154

Answers (1)

Igor R.
Igor R.

Reputation: 15085

The idea to define memebers as shared_ptr's to asio objects is ok. But you shouldn't destroy & create them every time again: 

if (!m_resolver)
{
  m_resolver.reset(...);
}

Besides, you can avoid explicit locks, if you ensure that all the operations on asio objects take place in the thread that runs io_service (assuming you've got a single thread per io_service). To do this, just separate the implementation of your interface functions and use post(). And of course, use shared_from_this idiom to simplify object lifetime control:

void CommandScreenshot::someMethod(Arg1 arg1, Arg2 arg2)            
{
  io_.post(bind(&CommandScreenshot::someMethodImpl, shared_from_this, arg1, arg2)); 
}
//...
void CommandScreenshot::someMethodImpl(Arg1 arg1, Arg2 arg2)            
{
  // do anything you want with m_resolver, m_socket etc.
}

Upvotes: 3

Related Questions