Open GoogleCodeExporter opened 8 years ago
I've understood what happened.
boost::asio uses additional thread to do getaddrinfo. The requests here may
take a few seconds to perform (or to timeout). When io_service is shutdown, it
does not cancel all operation in queue, instead it waits until whole queue is
processed. Which can take lots of time.
I don't know how to see the precise size of queue in debugger (as it is linked
list). But effectively program can not terminate in tens minutes.
Note: And stopped_ is false in task_io_service::do_run_one. If stopped_ were
true this loop would be breaked instantly.
Original comment by vanya...@gmail.com
on 14 Dec 2014 at 9:47
it's dangerous to stop the io_service with potentially critical jobs still in
the queue. however, perhaps all hostname lookups could be moved to their own
io_service and its own thread. that way just the DNS lookups could be cancelled.
it is a shame that DNS lookups can't be cancelled any other way (afaik) in
boost.asio.
Original comment by arvid.no...@gmail.com
on 14 Dec 2014 at 10:01
[deleted comment]
Here a few thoughts:
1. async_resolver has function cancel():
http://www.boost.org/doc/libs/1_51_0/doc/html/boost_asio/reference/ip__basic_res
olver/cancel.html Perhaps some calls to cancel() are missing?
2. The size of resolve queue is very large. Before I killed qbittorrent, 832
items had been processed.
3. The are lots of similar items in queue:
$ sort hosts-log | uniq -c
3 host: 10.rarbg.com
3 host: 10.rarbg.me
7 host: 11.rarbg.com
6 host: 11.rarbg.me
5 host: 9.rarbg.com
6 host: 9.rarbg.me
3 host: denis.stalker.h3q.com
3 host: fr33domtracker.h33t.com
143 host: open.demonii.com
26 host: tracker-ccc.de
19 host: tracker.ccc.de
194 host: tracker.istole.it
215 host: tracker.openbittorrent.com
193 host: tracker.publicbt.com
1 host: tracker.thepiratebay.org
5 host: tracker.torrentbox.com
I think if there are similar async_resolve requests in the queue libtorrent
could merge them in one. This will dramatically decrease the size of the queue.
Probably this even should be done on boost::asio level.
Original comment by vanya...@gmail.com
on 15 Dec 2014 at 8:57
I would expect the OS level lookup (getaddrinfo()) would cache results of
lookups.
The thing with basic_resolver::cancel() is that (iirc) it cancels all lookups.
Some lookups are actually required (or at least semi-important) during
shutdown, to send the stopped event to trackers.
Anyway, in trunk I added another layer on top of boost.asio's resolver to add
more aggressive caching and more aggressive timeout. I will look into improving
it further by being able to cancel less important lookups.
Original comment by arvid.no...@gmail.com
on 15 Dec 2014 at 9:36
Original issue reported on code.google.com by
vanya...@gmail.com
on 6 Dec 2014 at 12:28