boost::asio, threads and synchronization

Question

This is somewhat related to this question, but I think I need to know a little bit more. I\'ve been trying to get my head around how to do this for a few days (whilst working o

Answer 1

When data is received, how do people get the data back to the UI thread? In the past when I used completion ports, I made a special event that could post the data back to the main UI thread using a ::SendMessage. It wasn't elegant, but it worked

::PostMessage may be more appropriate.

Unless everything runs in one thread these mechanisms must be used to safely post events to the UI thread.

Answer 2

1) What is the best-practice way of using boost::asio in a client application with regard to threads and keeping them alive?

As the documentation suggests, a pool of threads invoking io_service::run is the most scalable and easiest to implement.

2) When writing to a socket from the main thread to the IO thread, is synchronization achieved using boost::asio::post, so that the call happens later in the io_service?

You will need to use a strand to protect any handlers that can be invoked by multiple threads. See this answer as it may help you, as well as this example.

3) When data is received, how do people get the data back to the UI thread? In the past when I used completion ports, I made a special event that could post the data back to the main UI thread using a ::SendMessage. It wasn't elegant, but it worked.

How about providing a callback in the form of a boost::function when you post an asynchronous event to the io_service? Then the event's handler can invoke the callback and update the UI with the results.

Answer 3

boost::io_service::run() will return only when there's nothing to do, so no async operations are pending, e.g. async accept/connection, async read/write or async timer wait. so before calling io_service::run() you first have to start any async op.

i haven't got do you have console or GUI app? in any case multithreading looks like a overkill. you can use Asio in conjunction with your message loop. if it's win32 GUI you can call io_service::run_one() from you OnIdle() handler. in case of console application you can setup deadline_timer that regularly checks (every 200ms?) for user input and use it with io_service::run(). everything in single thread to greatly simplify the solution

Answer 4

1) Have a look at io_service::work. As long as an work object exists io_service::run will not return. So if you start doing your clean up, destroy the work object, cancel any outstanding operations, for example an async_read on a socket, wait for run to return and clean up your resources.

2) io_service::post will asynchronously execute the given handler from a thread running the io_service. A callback can be used to get the result of the operation executed.

3) You needs some form of messaging system to inform your GUI thread of the new data. There are several possibilities here.

As far as your remark about the documention, I thing Asio is one of the better documented boost libraries and it comes with clear examples.