Conversation
|
Good catch, although I'm not sure that these changes would be sufficient to prevent future mistakes of this kind. Come to think of it, capturing the thread's stack to use it in another threads is perverse, but we don't have other way to represent return values with this API. Even if we had it, there's no way to prevent it with lambdas. On a side note, I never liked how we work with exceptions in ThreadPool -- it's not like the caller can get anything useful from a particular exception, so there is no benefit in saving and rethrowing them: we might as well just log them and then throw our own. Combined with the wonderful |
|
The tsan failure is the same we're seeing in master: https://clickhouse-test-reports.s3.yandex.net/0/6191c10abe246236cbc805cf8b1ea42dde3703db/stress_test_logs/test_output/stderr.log |
(cherry picked from commit 0046b9f)
|
conflict in 19.15 |
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Category (leave one):
Short description (up to few sentences):
Wait for all scheduled jobs, which are using local objects, if
ThreadPool::schedule(...)throws an exception. RenameThreadPool::schedule(...)toThreadPool::scheduleOrThrowOnError(...)and fix comments to make obvious that it may throw.