2

I'm using a fairly simple boost::asio set-up, where I call io_service.run() from the main thread. I have a tcp resolver, and use async resolve to look up an address. When that look-up fails, I throw an exception inside the asynchronous callback. I catch this exception outside the run() call, inside the main function. I then call stop() on my io_service instance (which is a global). However, when main() returns, the program hangs. It turns out to be waiting for an exit_event_ that never comes from the resolver service.

I do not wish to hang on exit. Is there something I'm doing wrong? If so, what? I haven't found much discussion about these things online. I'm using boost 1.41.0 on Windows 7/64bit.

NmdMystery
  • 2,778
  • 3
  • 32
  • 60
Jon Watte
  • 6,579
  • 4
  • 53
  • 63
  • 3
    just to clarify: io_service.run returns - and you catch the exception in a try-catch around the call to io_service.run? Please provide a code snippet demonstrating the problem. –  Jul 24 '10 at 09:37
  • nearly impossible to help without some code that reproduces the problem. – Sam Miller Jul 24 '10 at 12:59
  • i have exactlty the same problem, throwing an exception not frow a thread nor a call back but in an object method when other object (servers and client, posted async listen jobs) i catch the exception in try catch wraping io_service.run() et call return 1; but the programme never exit..and stay stuck in the io_service destructor... Did you resolved this issue? Our project is based on asio and im effraid using a buggy library... – MiniScalope Aug 25 '10 at 12:14
  • Alright i understood why, i have been fixed ;) – MiniScalope Aug 25 '10 at 12:22

2 Answers2

1

I then call stop() on my io_service

Try to use this trick (copied from io_service documentation) when you need to stop io_service:

boost::asio::io_service io_service;
auto_ptr<boost::asio::io_service::work> work(
    new boost::asio::io_service::work(io_service));
...
work.reset(); // Allow run() to exit.

The reason is simple (also from the documentation): call to io_service::stop() will cause the io_service run() call to return as soon as possible, abandoning unfinished operations and without permitting ready handlers to be dispatched.

So, calling io_service::stop() is not enough if you need to dispatch all handlers.

qehgt
  • 2,972
  • 1
  • 22
  • 36
0

stop() just signals the io_service to stop. If you follow the stop() call with another run() call it should return and clean up properly.

There is some discussion about throwing exceptions from handlers in the documentation.

I'm also guessing the issue may be related to some object lifetime issue, e.g. the io service is destroyed while something else is still referencing it. Take a closer look at the examples and how shared pointers are used to ensure the objects are still around.

Guy Sirton
  • 8,331
  • 2
  • 26
  • 36