-
Notifications
You must be signed in to change notification settings - Fork 419
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
[wjwwood] feat(MultiThreadedExecutor): Added ability to handle exceptions from threads #2505
base: rolling
Are you sure you want to change the base?
Conversation
…threads This commit adds external exception handling for the worker threads, allowing application code to implement custom exception handling. feat(Executor): Added spin API with exception handler. Signed-off-by: Janosch Machowinski <J.Machowinski@cellumation.com>
Signed-off-by: Janosch Machowinski <j.machowinski@cellumation.com>
|
@jmachowinski unfortunately I did not get this one in under the wire, nightly CI has the farm locked up now (we should consider putting the deadline just before nightly jobs start...), but ultimately this set of changes were not ideal I think, maybe you had a big reason for passing it as an argument for spin(), but if you didn't I think the change to allow it in the executor options was probably a better approach that was less disruptive. The trade-off, however, is that it's up to each executor to make sure they account for the exception handler in the options, whereas the new signature in this approach makes that hard to ignore. However, there still may be a path to the ExecutorOptions change in jazzy, but it will require an ABI change before the release, but one I think we really should make, which is to add a pimpl pointer in the Executor base class as well as one in the ExecutorOptions. That would allow us to extend the options and executor APIs without breaking ABI in existing releases if needed. I'll have to talk to the other maintainers about it, but maybe we can go that route. |
@wjwwood Thanks for the effort you put into the PRs ! Your latest changes will break debugging. As soon as you catch an exception, and rethrow it, the only backtrack you will get will point to the rethrow. That was the reason for the code duplication that was going on. |
I don't fully understand what you mean, but I can have a look tomorrow. Should be something we can fix after the API freeze. |
#include <stdexcept>
void origin()
{
throw std::runtime_error("Error in Origin");
}
void rethrow_fun()
{
try
{
origin();
}
catch(const std::exception &e)
{
throw;
}
}
int main()
{
rethrow_fun();
return 0;
}
MultiThreadedExecutor::spin()
{
spin([](const std::exception & e) {throw e;});
} With the construct above, you will only get stack traces, pointing to the lambda inside of spin, but no one pointing to the origin of the throw. This makes debugging almost impossible. But yes, changing this should have no effect on the external API/ABI |
We decided to not break the API freeze for these prs, but I did get tentative approval to add a pimpl pointer to the Executor and ExecutorOptions classes (ABI but not API breaking), which should let us address this problem between now and the release or just after the release, using the pimpl and new APIs (which are allowed). |
@wjwwood is there any update on this? |
const std::function<void(const std::exception & e)> & exception_handler) | ||
{ | ||
try { | ||
function(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is @jmachowinski trying to explain with #2505 (comment), i do not think this is gonna useful stack trace either.
Modified version of #2382