Mirror of YDB github repos https://code.mastervirt.ru/ydb/atom?h=CLI_2.30.0 2025-05-22T12:40:47Z 2025-05-22T12:40:47Z a11ax a11ax@yandex-team.com 2025-05-22T12:00:59Z urn:sha1:c28fa5a5d4eee687fa35713a3b8561b8f892992a Было: при добавлении-удалении обьекта берем мьютекс, молимся чтобы тот не оказался залочен при форке, никак перед форком на лок не смотрим Помимо того что это просто не очень надежно, оно не всегда работает. Может случиться так что с мьютексом все нормально, но IntrusiveList все равно [скорапчен](HIDDEN_URL и список закольцован не там где надо (по всей видимости cpu reorder на apple m1 ехидничает). Стало: берем спинлок вместо мьютекса, в том числе берем его на время форка. commit_hash:94145ab392390a2c0b9f885275302082524606b2 2025-03-28T08:26:21Z andybg andybg@yandex-team.com 2025-03-28T08:11:49Z urn:sha1:93724f9cd4e5c28a1e154375e40cb9722bcdb698 Продолжение починки крэшей при форке Ситуация такая же - используем subprocess для обработки данных ( subprocess не наши, написаны множеством команд на нескольких языках под конкретные ситуации), быстро избавиться от форка не получится. Есть шанс избавиться от этого пул треда, но тоже не быстро. Предлагается простое решение - не вызывать `TAtforkQueueRestarter::Get()`совсем, тогда не будет создание singletonа и вызова `pthread_atfork`. Все это под опцией `SetForkAware` - кто хочет может ее включать, для всех остальных ничего не изменится. Полная обратная совместимость, фикс ничего не мог зацепить. Проверил локально, вызова `pthread_atfork` нет в `unified agent` больше. Тесты на это очень сложно написать, без больших изменений в тред пуле, пробовал с перехватом `pthread_atfork`, к сожалении, не только `TAtforkQueueRestarter` им пользуется и нормально перехватить тоже не получилось. commit_hash:3711c6175ca64564f31f811ee1308d70ef6eb5e3 2024-09-05T17:17:10Z dmasloff dmasloff@yandex-team.com 2024-09-05T17:05:47Z urn:sha1:74184a40c15dc0649a769d9754d0ce7efb44db04 FixNamespaceComments in /util bb9152570d7c258798644ead5a59f604de05ef3b 2024-08-17T20:43:45Z dmasloff dmasloff@yandex-team.com 2024-08-17T20:33:42Z urn:sha1:69340f4614e853b9319df4b454ab7497711ee3cd Set SpacesInLineCommentPrefix to 1 in /util 3853f9ec5143722c1bebd8dc0ffc9b61a6c17657 2024-01-09T17:56:40Z AlexSm alex@ydb.tech 2024-01-09T17:56:40Z urn:sha1:e95f266d2a3e48e62015220588a4fd73d5d5a5cb 2023-10-10T07:26:34Z ilnurkh ilnurkh@yandex-team.com 2023-10-10T07:09:12Z urn:sha1:335c640261b6272bc052a251d9b8780150090b45 https://clubs.at.yandex-team.ru/arcadia/29404 2022-11-10T09:04:05Z sskvor sskvor@yandex-team.com 2022-11-10T09:04:05Z urn:sha1:6d5ed9f0166178823f3a752bfe46dd7ef5042df8 Контекст. В древнем странном коде обнаружили, что если создавать `TThreadPool` часто и конкуретно с запуском `TShellCommand`, то иногда последняя дедлочится: если начали выполнять конструктор `TThreadPool` и регистрацию в `TAtforkQueueRestarter`, захватив `TAtforkQueueRestarter::ActionMutex`, а в другом потоке параллельно сделали `fork`, то последний может форкнуться с залоченым мьютексом. Первым делом происходит вызов коллбеков из `pthread_atfork`, где мьютекс лочится заново. Конечно, форкаться в сложных программах с тредпулами категорически запрещено, но, подозреваю, много кода в аркадии так написано. Давайте как-то защитимся от такого. 2022-05-17T07:48:10Z eeight eeight@yandex-team.ru 2022-05-17T07:48:10Z urn:sha1:1e1dfc1b3545147948cc2190bb15161f630507e9 ref:3fa56aa890b75b7301a3193c2ee40106281a71cb 2022-05-11T07:40:18Z eeight eeight@yandex-team.ru 2022-05-11T07:40:18Z urn:sha1:05a6fea78142058210511273b3ece21050ad137b ref:39a714b781c60dca9e3b946d870971076e14ab7c 2022-02-10T13:52:02Z seege seege@yandex-team.ru 2022-02-10T13:52:02Z urn:sha1:e7d460ea3389cb4f573ef5fb09f7072549a17765