-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-throw boost::coroutines::detail::forced_unwind #7351
Comments
Actually this causes problems, especially on Windows with #7431. There's two things to fix:
See boostorg/coroutine#39 for details. |
For the HttpServerConnection class this is already done with #7477. |
The wrapper is inspired by https://github.com/niekbouman/commelec-api/blob/master/commelec-api/coroutine-exception.hpp#L35 |
Defer() calls are also a TODO. |
Exceptions in Disconnect() might be thrown (this has been reworked into error_code locally) which are swallowed inside the Destructor for being dangerous. On the other hand, swallowing them may corrupt the stack unwinding operation from the coroutine layer. The best is to avoid Defer inside lib/remote and call Disconnect() directly after breaking from other operations. refs #7351 refs #7431
All things are implemented and the stack unwind works in both HTTP and JSON-RPC. |
At the moment some of our coroutines catch exceptions during async ops, but none of them re-throw
boost::coroutines::detail::forced_unwind
. They have to re-throw that exception unconditionally.There aren't any visible problems yet as we cheat our static destructors, but IMO we should not rely on this.
The text was updated successfully, but these errors were encountered: