Re: [asio-users] host_resolver and demuxer::work
Brought to you by:
chris_kohlhoff
From: Christopher K. <ch...@ko...> - 2006-01-17 05:17:24
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > I was a bit surprised that waiting for an > async_get_host_by_name() on a host_resolver wouldn't be > considered as "work" by the demuxer::run () function. i.e. it > returned when the only operation I had pending was a name > lookup. > > I find this to be a bit unexpected. Hmm, sounds like a bug. There is a demuxer::work member variable inside the asio::ipv4::detail::host_resolver_service's nested class get_host_by_name_handler, so I'm not sure why it should've returned early. > Anyway, my attempt to work around this was to us a > demuxer::work instance to pass along with my handler (by > value) for the async_get_host_by_name() operation. That's > when I encountered the second problem. > > From what I can understand (didn't investigate too > thoroughly), it looks like asio deadlocks when the handler > object is being copied, and the work instance is destructed. > > The destructor will lock the demuxer/reactor before it > decrements the work counter, but the lock is already held by > that thread, and it is not a recursive mutex. Can you show me the callstack when the deadlock occurs? I have already fixed another couple of deadlock bugs since 0.3.6 that were a side effect of adding the demuxer::work class. Maybe this one is related. Cheers, Chris |