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 template <typename ReturnType> pattern, finding out what scheduleImpl really does with exception is just hopeless. Maybe I should rewrite it to also fix the crazy msan failure there that I still haven't been able to debug.

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
Will merge as is.

conflict in 19.15