Я реализовал клиентскую серверную программу, используя boost :: asio library. В моей реализации есть моменты, когда io_service.run() блокируется бесконечно. В случае, если я передаю другой запрос io_service, заблокированный вызов начинает выполняться нормально.заблокированные запросы в io_service
Есть ли способ увидеть, какие ожидающие запросы находятся в очереди io_service?
Я не использовал рабочий объект, чтобы заблокировать вызов вызова!
Нет официальных способов запроса в io_service, чтобы найти все незавершенные запросы. Однако есть несколько методов для решения проблемы:
BOOST_ASIO_ENABLE_HANDLER_TRACKING и Boost.Asio будет записывать выходные данные отладки, включая отметки времени, идентификатор и тип операции, в стандартный поток ошибок.epoll_reactor.Наконец, если вы считаете, что это ошибка, возможно, стоит обновить ее до последней версии или проверить revision history на предмет соответствующих изменений. Несмотря на это, более детальное описание проблемы может позволить другим помочь определить источник проблемы и возможные решения.
Теперь я потратил несколько часов на чтение и экспериментирование (мне нужно больше boost :: asio для работы), и получается: вид. Но это не так просто или понятно, как можно было бы надеяться.
Под капотом (ну, под самым верхним капюшоном) io_service имеет кучу других зарегистрированных услуг, которые выполняют работу async_ операций соответствующих полей. Это «Услуги», описанные в ссылке. Теперь, к сожалению, услуги остаются зарегистрированными, а там есть работа или нет. Например, если ваш io_service имеет udp-сокет, он все равно будет иметь все соответствующие службы, даже если сам сокет неактивен.
Но вы можете задать свой io_service, какие услуги у него есть. Допустим, вы хотите знать, что ваш io_service под названием m_io_service имеет udp datagram_socket_service. Тогда вы можете назвать что-то вроде:
if (boost::asio::has_service<boost::asio::datagram_socket_service<boost::asio::ip::udp> >(m_io_service))
{
//Whatever
}
Это не помогает много, потому что это не будет верно независимо от того, кастрированный баран сокет активен или нет. Но после того, как вы знаете, что у вас есть эта услуга, вы можете получить ссылку на нее, используя use_service вместо has_service, но с тем же элегантным количеством <>. И теперь вы можете проверить сервис, чтобы узнать, для чего он нужен. К сожалению, он не скажет вам, какие имена выдающихся обработчиков (вероятно, частично потому, что они их не знают), но если это сокет, вы можете получить его implemention_type и с этой проверкой, находится ли он в настоящее время is_open или найти либо local_endpoint, как remote_endpoint.
В случае deadline_timer_service вы можете, помимо прочего, узнать, когда это expires_at.
См. Ссылку для получения дополнительной информации о том, что такое служба, и не желает вам сообщать. http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference.html
Эта информация, мы надеемся, позволит вам определить, какая операция async_ не вернулась. И если нет, то, по крайней мере, вы можете cancel любых неожиданно активных сервисов.
Не то, чтобы я знал. Не зная, что вы делаете, трудно узнать, что вас блокирует. Разве вы раскошелили свое заявление? Не вернулся ли какой-либо из ваших обработчиков? Пользователь deadline_timer не отменен? Если вы ничего не можете найти, вы всегда можете использовать более одного io_service. Может быть, один на сокет, чтобы вы могли выследить оскорбительный звонок. Вы также можете «остановить» ваш io_service, когда считаете, что все сделано. Или вы просто отменяете каждую асинхронную операцию в своих обработчиках и при необходимости перезапускаете их. Или не 'run', а' poll', поэтому вы держите контроль над тем, что происходит, когда. – DeVadder