Are multiple ASIO io_services a good thing?

Question

I've begun using Boost.ASIO for some simple network programming, my understanding of the library is not a great deal, so please bear with me and my newbie question.

At the moment in my project I only have 1 io_service object. Which use for all the async I/O operations etc.

My understanding is that one can create multiple threads and pass the run method of an io_service instance to the thread to provide more threads to the io_service.

My question: Is it good design to have multiple io_service objects? say for example have 2 distinct io_service instances, each with 2 threads associated, do they somehow know about each other (and hence cooperate with each), or if not would they negatively affect each other?

My intention is to have 1 io_service for socket based I/O and another for serial based (tty) I/O.

Dashtilut

I think its better to have 1 single io_service per application and just add as many threads as you like to service the operations. – Dangle

Answer 1

We use multiple io_service's because some of the components in our application need to run all their worker threads at certain fixed priorities, different for each component. Thus each component is given its own io_service, and each component has its own pool of threads executing run().

Other designs I could think of would be if a different number of threads in the pool is required for each IO, or, more relevant to your case, is if the pool cannot be shared because, for example, if your network IO can take out every thread and leave your serial IO waiting.

Unarmed

Answer 2

IIRC, during Michael Caisse's Boostcon ASIO talk (which is worth watching anyway), I believe this question is explicitly asked by an audience member and ok'd as a potential solution. I take from that that it's not wrong per se, and can be used that way according to your design.

Perspective

The link says it's not ready to be watched.. Do everyone get that error message? – Delorisdelorme

@Default: I see the same problem as well, is it available on youtube? – Fishtail

Hrm. Well, it's the same result from the link in the Boost Dev mailing list on Sep 28 2010, which I watched back then. Dunno why it's broken :( – Perspective

Some slides from ppt dl.dropbox.com/u/10282384/asio_presentation_with_story.pdf https://mcmap.net/q/588705/-boost-asio-architecture-document – Walls

The slides are now available here: cierelabs.com/slides/asio_presentation_with_story.pdf – Changeling

Answer 3

This discussion may be enlightening:

http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300

I don't have the code right here, but why would you use multiple io_services? I thought it used one io_service and multiple threads executing run on that one io_service.

IIUC, each io_service owns a select/epoll/whatever queue, so having multiple io_services is akin to having multiple independent select/epoll loops. In some situations, eg. large numbers of sockets and multiple CPUs, this might help.

Something I'm less sure about is with multiple threads all running io_service::run (with the same io_service). I think this just means the handlers are run concurrently, while the select/epoll/etc. loop is 'shared'. I think this is best for when your handlers are relatively long-running operations.

Perdita