2

My boost server accidentally stopped accepting incoming connections because some other guy from my team created yet another server using boost acceptor in a different thread (using different port)? Is it normal and how make them two servers work independently and not messing with each other?

SOLVED: acceptors had nothing to do with it, the guy started an infinite loop somewhere that blocked other components. I guess that is what happens when the team is working uncoordinated :( Sorry guys, sehe's the best as always

Nikolay Kovalenko
  • 1,767
  • 2
  • 13
  • 14
  • I'm voting to close this question as off-topic because the root cause of the problem was elsewhere – Nikolay Kovalenko Dec 20 '18 at 20:07
  • To be fair, this kind of post is uncannily useful in a serendipitous way. Often the things that trip up one project also creep up in another. A good example of it would be [this kind](https://stackoverflow.com/questions/17899508/corrupted-double-linked-list/17899692#17899692) or [this](https://stackoverflow.com/questions/7124489/unix-sort-command-takes-much-longer-depending-on-where-it-is-executed-fastest/7150015#7150015). I think your question is fine for SO. (Not even mentioning hangups like [these](https://stackoverflow.com/questions/9207954/visual-studio-find-in-files/9208041#9208041)) – sehe Dec 20 '18 at 22:35

1 Answers1

5

We're using multiple acceptors with a single io_service just fine, as by design.

Also, we're sharing out work across multiple other io_service instances, using the same sockets, just fine, as by design.

What could be happening in your code base would be antipatterns: if people call stop() on your io_service instance then yes that would wreak havoc on any other async operations also queued on the same instance.

So, in general, the idea would be to avoid using stop() or similar "life-time" operations on a shared io_service instance. The only appropriate time for such a call would be during a forced shutdown sequence, but really graceful shutdown should let all active connections shutdown and the pending work to be drained, so that threads running io_service::run would spontaneously complete anyways.

See also:

sehe
  • 374,641
  • 47
  • 450
  • 633
  • @theshmoo since you asked nicely on the now-deleted answer: added links to samples. Especially the last link has an elaborate sample setup that also goes into detail about graceful shutdown – sehe Dec 20 '18 at 17:17