You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We usually run parallel solving across multiple threads, e.g. for CVRP here. The problem is that if a worker thread were to throw for an unexpected reason, the current code would not propagate the exception to the main thread. I simulated this by throwing a std::runtime_error from LocalSearch::run, which result in an ugly:
terminate called recursively
terminate called after throwing an instance of 'Aborted (core dumped)
whereas we'd like to gracefully exit with what feedback we can {"code": 1, "Internal error: ..."}.
The good news is I've had no report of this kind of failure so far
Obviously this is related to the fact that the lambda used with std::thread only calls functions that are free of any throw clause (heuristics and local search stuff). So basically we're safe as far as our own code is concerned, but not if some standard library call does throw somewhere down the line.
My first though was that we should mark the lambda function (and maybe functions used by it) as noexcept. While this may be a good practice, it does not guarantee a compile-time check ensuring no exception will ever go through. The behavior when marking the lamba as noexcept and throwing from inside is that we get a call to std::terminate. This does not solve the need for a clean exit with an error.
My conclusion is that we should still catch/rethrow exceptions from the threads to be safe. Happy to have some feedback from others with more experience though!
We usually run parallel solving across multiple threads, e.g. for CVRP here. The problem is that if a worker thread were to throw for an unexpected reason, the current code would not propagate the exception to the main thread. I simulated this by throwing a
std::runtime_error
fromLocalSearch::run
, which result in an ugly:whereas we'd like to gracefully exit with what feedback we can
{"code": 1, "Internal error: ..."}
.The good news is I've had no report of this kind of failure so far but we should nevertheless use
std::exception_ptr
to handle this correctly, see e.g. https://vorbrodt.blog/2019/03/24/propagate-exceptions-across-threads/.The text was updated successfully, but these errors were encountered: