boost :: asio :: yield_context: неожиданное исключение принудительного_решения

Я пытаюсь написать свою собственную асинхронную функцию для boost :: asio, как описано Вот.

Однако я получаю повышение :: coroutines :: detail :: принудительное_unwind исключение на линии с result.get

#include <boost/chrono.hpp>
#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/asio/steady_timer.hpp>

#include <iostream>

namespace asio = ::boost::asio;template <typename Timer, typename Token>
auto my_timer (Timer& timer, Token&& token)
{
typename asio::handler_type<Token,
void (::boost::system::error_code const)>::type
handler (std::forward<Token> (token));

asio::async_result<decltype (handler)> result (handler);

timer.async_wait (handler);
return result.get (); // Got forced_unwind exception here.
}

int main ()
{
asio::io_service io;
asio::steady_timer timer (io, ::boost::chrono::seconds (1));

asio::spawn (io, [&] (asio::yield_context yield)
{
try {
std::cout << "my_timer enter\n";
my_timer (timer, yield);
std::cout << "my_timer returns\n";
}
catch (const boost::coroutines::detail::forced_unwind& e)
{
std::cout << "boost::coroutines::detail::forced_unwind\n";
}
}
);

io.run ();
}

Тот же код на Coliru

ОБНОВИТЬ:

Поведение существует на:

Darwin 14.0.0 (MacOS 10.10)
clang version 3.6.0 (trunk 216817) and gcc version 4.9.1 (MacPorts gcc49 4.9.1_1)
boost 1.57

а также

Red Hat 6.5
gcc version 4.7.2 20121015 (Red Hat 4.7.2-5) (GCC)
boost 1.57 and 1.56
(the example code was trivially modified because gcc 4.7 does not support c++14 mode)

9

Решение

Короче говоря, вам нужно создать копию обработчика, например, разместив ее в io_serviceпрежде чем пытаться получить async_result чтобы поддержать сопрограмму.


Boost.Asio предотвращает бессрочную приостановку сопрограммы на неопределенный срок, уничтожая сопрограмму, в результате чего стек сопрограммы разматывается. Объект сопрограммы бросит boost::coroutines::detail::forced_unwind во время его разрушения, в результате чего подвесной стек раскручивается. Asio выполняет это:

  • yield_context CompletionToken поддерживает weak_ptr в сопрограмму.
  • Когда специализированный handler_type::type обработчик построен, он получает shared_ptr для сопрограммы через CompletionToken’s weak_ptr, Когда обработчик передается как обработчик завершения асинхронным операциям, обработчик и его shared_ptr копируются. Когда обработчик вызывается, он возобновляет сопрограмму.
  • При вызове async_result::get(), специализация сбросит сопрограмму shared_ptr принадлежит обработчику, который был передан async_result во время строительства, а затем дать сопрограмму.

Вот попытка проиллюстрировать выполнение кода. Пути в | указать активный стек, : указывает на приостановленный стек, а стрелки используются для обозначения передачи управления:

boost::asio::io_service io_service;
boost::asio::spawn(io_service, &my_timer);
`-- dispatch a coroutine creator
into the io_service.
io_service.run();
|-- invoke the coroutine entry
|   handler.
|   |-- create coroutine
|   |   (count: 1)
|   |-- start coroutine        ----> my_timer()
:   :                                |-- create handler1 (count: 2)
:   :                                |-- create asnyc_result1(handler1)
:   :                                |-- timer.async_wait(handler)
:   :                                |   |-- create handler2 (count: 3)
:   :                                |   |-- create async_result2(handler2)
:   :                                |   |-- create operation and copy
:   :                                |   |   handler3 (count: 4)
:   :                                |   `-- async_result2.get()
:   :                                |       |-- handler2.reset() (count: 3)
|   `-- return                 <---- |       `-- yield
|       `-- ~entry handler           :
|           (count: 2)               :
|-- io_service has work (the         :
|   async_wait operation)            :
|   ...async wait completes...       :
|-- invoke handler3                  :
|   |-- resume                 ----> |-- async_result1.get()
:   :                                |   |--  handler1.reset() (count: 1)
|   `-- return                 <---- |   `-- yield
|       `-- ~handler3                :       :
|           |  (count: 0)            :       :
|           `-- ~coroutine()   ----> |       `-- throw forced_unwind

Чтобы исправить эту проблему, handler должен быть скопирован и вызван через asio_handler_invoke() когда пришло время возобновить сопрограмму. Например, следующее опубликует обработчик завершения1 в io_service это вызывает копию handler:

timer.async_wait (handler);

timer.get_io_service().post(
std::bind([](decltype(handler) handler)
{
boost::system::error_code error;
// Handler must be invoked through asio_handler_invoke hooks
// to properly synchronize with the coroutine's execution
// context.
using boost::asio::asio_handler_invoke;
asio_handler_invoke(std::bind(handler, error), &handler);
}, handler)
);
return result.get ();

Как продемонстрировано Вот, с этим дополнительным кодом, вывод становится:

my_timer enter
my_timer returns

1. Код обработчика завершения, вероятно, можно немного очистить, но, как я отвечал как возобновить стог сопрограммы Boost.Asio из другого потока, Я заметил, что некоторые компиляторы выбирают неправильно asio_handler_invoke крюк.

9

Другие решения

Это деталь реализации Boost Coroutine.

Как задокументировано здесь: исключения

Код, выполняемый функцией сопрограммы, не должен препятствовать распространению detail::forced_unwind exception, Поглощение этого исключения приведет к сбою разматывания стека. Таким образом, любой код, который перехватывает все исключения, долженthrow любое ожидание detail::forced_unwind исключение.

Итак, вы явно требуется чтобы пропустить это исключение. Явно закодируйте обработчик как:

Жить на Колиру

try {
std::cout << "my_timer enter\n";
my_timer(timer, yield);
std::cout << "my_timer returns\n";
}
catch (boost::coroutines::detail::forced_unwind const& e)
{
throw; // required for Boost Coroutine!
}
catch (std::exception const& e)
{
std::cout << "exception '" << e.what() << "'\n";
}

Это конкретное исключение является подробностью реализации и должно

  • ожидать в сопрограммном контексте
  • не глотать, иначе семантика RAII будет нарушена, что приведет к утечке ресурсов и, возможно, неопределенному поведению с вашим типом RAII.

Честно говоря, это делает небезопасным «наивное» использование существующего (унаследованного) кода, который может не дать такой гарантии. Я думаю, что это очень веская причина для

  • руководящие принципы против неспецифических уловов, за исключением голый Rethrow
  • стратегии централизованного исключения (например, используя функцию Липпинкотта для обработчиков исключений)

    Помните, что последняя идея может быть прямо запрещена и в сопрограммах:

    Не прыгайте изнутри блока catch, а затем повторно генерируйте исключение в другом контексте выполнения.

    Обновить: Как @DeadMG только что прокомментировал эту статью, мы можем тривиально преобразовать функцию Липпинкотта в функцию обтекания, которая могла бы удовлетворить требования к Coroutine при централизованной обработке исключений.

4

По вопросам рекламы [email protected]