Но неужели мы одни такие умники, кто решил взять управление стеками в свои руки? Конечно же нет! На самом деле за этим потрясающая история, длиною как минимум в 14 лет. Пронаблюдать ее можно вот в этом древнем, но открытом ишуе: https://sourceware.org/bugzilla/show_bug.cgi?id=11787

Краткий пересказ:

На дворе 2010 год.

*вот вы помните, что вы делали в 2010 году? я помню: заканчивал второй курс, матан сдавал последний раз, собирался специализироваться на вычмате*

В багтрекер glibc приходит пользователь (догадываюсь, что из Гугла) и описывает схожую проблему: в хроме создаются треды со стеком 128К. Обычно все нормально, но в профилировочном режиме начинает активно использоваться TLS, поэтому pthread_create перестает работать. Далее диалог мейнтейнера с репортером:

М: да, мы TLS на стеке аллоцируем, все верно. А вы что хотели?

Р: хотели, чтобы когда мы запрашиваем стек 128К, у нас было бы в распоряжении 128К. Вроде логично?

М:

The "stack" is purposely ambiguous and once handed over to the implementation the implementation has complete control and can do what it wishes including use some of it for TLS which is what we do.

В общем, мейнтейнер упрямится: говорит, что нужно обсудить это с представителями основных дистрибутивов, зовет их в тред, все вместе думают. Обсуждение приходит к необходимости эвристики: когда можно TLS на стеке оставлять, а когда все-таки нет. Уже даже патч готов, но его не принимают, т.к. это все еще выглядит, как слишком большое и опасное изменение. Изначальное обсуждение длится уже 2 года.

—

Наступает 2013 год.

*я уже закончил бакалавриат, женился и 2 года, как работаю в Excelsior, а вы?*

В тред возвращается репортер, спрашивет: как там прогресс? А то абсолютно тоже самое случилось с JVM и JNI: если создавать JVM из нативного кода, где много __thread переменных, то Java треды потом не создаются.

Еще в тред приходит разработчик musl и рассказывает, что там проблема решена: они аккуратно оценивают запрошенный размер стека и размер TLS, если TLS больше, чем 1/8 размера памяти, которую выдали под стек, то он аллоцируется отдельно.

Мейнтенер обещает вернутся к этой таске на следующей неделе.

—

Дальше сообщения уже за 2015 год.

*у меня первый год в аспирантуре (я уверен, что защищусь), наконец сдал на права и купил первую свою машину*

Оказывается, что с похожими проблемами сталкиваются рантаймы разных языков: Rust, Java, Ruby, скорее всего и Go. Веры в то, что в glibc это поправят, у них особо нет, поэтому они хачат: зовут приватную функцию __pthread_get_minstack, получают размер static TLS и учитывают его в своих запросах в pthread_create.

Мейнтейнер соглашается, что дело то, похоже, серьезное, так что он точно скоро им займется.

—

2017-2020 годы.

*сколько же тут всего у меня было? Первые доклады, JUGNsk, Колька, переход в Huawei, первый SnowOne*

Уже довольно редкие сообщения от новых репортеров из разных компаний о том, что они столкнулись с проблемой, нашли workaround в коде HS и применили его. Но было бы неплохо починить в glibc. Мейнтейнер согласен и благодарит их за информацию. Это поможет ему приоритезировать этот таск.

—

Последнее сообщение датируется 2022 годом.

*стартуем SysPro, решаю оставаться в РФ на фоне всего происходящего*

Какой-то такой же археолог описывает текущее состояние дел: код порефакторили, но основная логика осталась такой же. В musl все хорошо с их эвристикой. В хроме проблема больше неактуальна (этот кусок кода переписали), но в целом - проблема никуда не делась. Мейнтейнер не отвечает.

—

2024 год, с этим, наконец, столкнулись и мы.

Думаю, нужно ли дописать что-то в тот тред? Прикоснуться к истории еще сильнее? Наверное, ограничусь этим блогпостом, да буду дергать приватную __pthread_get_minstack, чтобы учесть ее в общем размере стека. Получается, что поднимаем цены (реальные запрашиваемые размеры стека), чтобы покрыть налоги от glibc.

—

Вот как бывает: у кого-то половина осознанной жизни прошла, а у кого-то ишуй так статус и не поменял. Ну, что поделать! В конце концов, что такое для системного программирования каких-то 14 лет?

#дух_машины