aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/tools/python3/Python/Python-ast.c
diff options
context:
space:
mode:
authorandybg <andybg@yandex-team.com>2025-03-28 11:11:49 +0300
committerandybg <andybg@yandex-team.com>2025-03-28 11:26:21 +0300
commit93724f9cd4e5c28a1e154375e40cb9722bcdb698 (patch)
tree48cd143b7d1dc68fee44f96edda2c6750227100d /contrib/tools/python3/Python/Python-ast.c
parent71e9df83f284bf42c2f8ea872752bf02e1055555 (diff)
downloadydb-93724f9cd4e5c28a1e154375e40cb9722bcdb698.tar.gz
Add an option to disable the fork aware mode for TThreadPool
Продолжение починки крэшей при форке Ситуация такая же - используем subprocess для обработки данных ( subprocess не наши, написаны множеством команд на нескольких языках под конкретные ситуации), быстро избавиться от форка не получится. Есть шанс избавиться от этого пул треда, но тоже не быстро. Предлагается простое решение - не вызывать `TAtforkQueueRestarter::Get()`совсем, тогда не будет создание singletonа и вызова `pthread_atfork`. Все это под опцией `SetForkAware` - кто хочет может ее включать, для всех остальных ничего не изменится. Полная обратная совместимость, фикс ничего не мог зацепить. Проверил локально, вызова `pthread_atfork` нет в `unified agent` больше. Тесты на это очень сложно написать, без больших изменений в тред пуле, пробовал с перехватом `pthread_atfork`, к сожалении, не только `TAtforkQueueRestarter` им пользуется и нормально перехватить тоже не получилось. commit_hash:3711c6175ca64564f31f811ee1308d70ef6eb5e3
Diffstat (limited to 'contrib/tools/python3/Python/Python-ast.c')
0 files changed, 0 insertions, 0 deletions