In Boost:asio how to reserve one thread for any particular activity

Question

I am creating an HTTP client where I need to push data to server. Things are working fine, now the requirement is that there should be one dedicated connection established with server for some priority data. For e.g. I have 2 HTTP connections open with server then one connection should always be available to push high priority data to server and where as the other connection can be used for pushing rest of stuff.

I tried with make_strands using this however that puts my activities in sequential execution.

I also tried with multiple io_context but it adds additional complexities. Is there any simple way to fulfill the requirement. Thanks.

question from:https://stackoverflow.com/questions/65951217/in-boostasio-how-to-reserve-one-thread-for-any-particular-activity

Answer 1

I also tried with multiple io_context but it adds additional complexities.

I think this is a basic misconception: it doesn't actually (as long as you don't explicitly bind handlers to executors from a different execution context, perhaps. But such a thing is hard to do accidentally).

---

Now if the requirement is:

For e.g. I have 2 HTTP connections open with server then one connection should always be available to push high priority data to server and where as the other connection can be used for pushing rest of stuff.

Then the answer is you can all that without using multiple threads at all. If you appear to require threads still, this indicates that you're performing longer running tasks inside handlers (blocking the io thread(s)).

Indeed in such case you may indeed want to have a dedicated execution context that is being run on a separate thread(s).

The simplest solution given your pre-existing situation would be to, indeed, have a second io_context that you run from its own thread.

My more common guideline would be the inverse: prevent the situation you have by never executing any blocking tasks on the UI thread. This leads to a design where I have only one IO thread usually, and the actual work gets put on task queues that can be serviced from a thread pool. Only when the task ready to send a response, they will post their IO operation to the IO context.

As you probably know complexity is easier to prevent than it is to achieve simplicity after-the-fact.