Интеграция C++ с Python и Go: чек-лист перед продакшеном

Вы обернули C++-код в Python-расширение или подключили его к Go через cgo, локальные тесты зелёные, вы катите в прод — и через сутки получаете сегфолт в потоке, который не воспроизводится на машине разработчика. Классический сценарий: код, который работает в один поток и на маленьких данных, разваливается под конкурентной нагрузкой и на объёмах, где менеджер памяти начинает двигать буферы. Ниже — чек-лист вещей, которые проверяют перед тем, как отдать такую интеграцию в эксплуатацию.

Статья не про то, как написать первый биндинг — про то, что ломается, когда он уже написан. Углы для Python (через pybind11 и стабильный C ABI) и Go (через cgo) разные, поэтому разбираем их отдельно, а в конце сводим в общую таблицу решений.

Общая модель: где проходит граница

И в Python, и в Go проблема одна — на стыке двух рантаймов встречаются два разных представления об управлении памятью, ошибками и потоками. C++ владеет памятью через RAII и деструкторы, кидает исключения, ничего не знает о планировщике вызывающей стороны. Python управляет объектами через подсчёт ссылок под защитой GIL. Go двигает горутины по потокам ОС и имеет собственный сборщик мусора, который может перемещать стеки.

Три вопроса, которые определяют, взорвётся ли интеграция под нагрузкой:

• Кто владеет каждым куском памяти и кто его освобождает.
• Что происходит с исключением C++, которое долетает до границы.
• Держите ли вы GIL (Python) или блокируете ли поток ОС (Go), пока крутится долгий C++-код.

Python: pybind11 и подводные камни

GIL и долгие вычисления

Если ваша C++-функция считает пять секунд и не отпускает GIL, весь Python-процесс на эти пять секунд встаёт: другие потоки не выполняются. Для CPU-тяжёлого кода это убивает смысл многопоточности на стороне Python.

В pybind11 (проверялось на 2.11.x) GIL отпускают явным guard-объектом на время работы чистого C++-кода, который не трогает Python-объекты:

#include <pybind11/pybind11.h>
namespace py = pybind11;

double heavy_compute(const std::vector<double>& data) {
    double result = 0.0;
    for (double value : data) {
        result += value * value; // тяжёлый цикл, Python-объектов не касается
    }
    return result;
}

PYBIND11_MODULE(mymodule, m) {
    m.def("heavy_compute", [](const std::vector<double>& data) {
        // отпускаем GIL на время расчёта, чтобы не блокировать интерпретатор
        py::gil_scoped_release release;
        return heavy_compute(data);
    });
}

Правило жёсткое: пока GIL отпущен, из этого кода нельзя трогать ни один Python-объект — ни создавать, ни удалять, ни менять счётчик ссылок. Нарушение даёт порчу памяти, которая проявится через часы работы.

Кто освобождает буфер

Самая частая утечка на этой границе — C++ выделяет массив через new[], отдаёт указатель в Python как обёрнутый объект, а деструктор не привязан. pybind11 решает это через политики владения (return_value_policy): по умолчанию для указателей действует automatic, но для сырых указателей на буферы, которыми вы владеете, задавайте политику осознанно. Если C++ возвращает ссылку на внутренний буфер объекта, а сам объект переживёт этот буфер, вам нужен keep_alive, иначе получите dangling pointer.

Проверка перед продом: на каждый указатель, пересекающий границу, вы можете назвать вслух, кто и когда его освободит. Если формулировка звучит как «наверное, сборщик разберётся» — интеграция не готова.

Исключения

C++-исключение, не пойманное на границе, — это неопределённое поведение для интерпретатора. pybind11 автоматически транслирует стандартные исключения (std::runtime_error → RuntimeError и так далее), но ваши собственные типы исключений нужно регистрировать через py::register_exception. Иначе исключение вашего типа долетит до Python как непонятный SystemError в лучшем случае и как краш — в худшем.

Go: cgo и его цена

Накладные расходы на вызов

Вызов C-функции из Go через cgo — не бесплатный переход, как между Go-функциями. Он включает переключение с горутины на системный поток и снятие ограничений планировщика. Порядок величины — десятки-сотни наносекунд на вызов против единиц для обычного Go-вызова. Это не проблема для одного вызова на запрос, но убивает производительность, если вы дёргаете C++ в горячем цикле миллионы раз.

Практический вывод: проектируйте границу крупноблочно. Передавайте на C++-сторону массив из миллиона элементов одним вызовом, а не вызывайте C++-функцию миллион раз в цикле Go.

Память и сборщик мусора Go

Ключевое правило cgo: нельзя хранить в C++-структуре указатель на память, выделенную Go, после возврата из вызова. Сборщик мусора Go может переместить или освободить эту память. Если C++ должен долго держать данные — копируйте их на C-стороне через malloc и явно освобождайте. Go предоставляет C.CString для строк, но возвращённый указатель вы обязаны освободить сами:

package main

/*
#include <stdlib.h>
#include "myengine.h" // объявляет process_data(const char*)
*/
import "C"
import "unsafe"

func Process(payload string) {
    // C.CString выделяет память в C-куче, Go её не отслеживает
    cPayload := C.CString(payload)
    // освобождаем вручную, иначе утечка на каждый вызов
    defer C.free(unsafe.Pointer(cPayload))

    C.process_data(cPayload)
}

Компилятор Go проверяет часть таких правил через флаг детектора указателей, но не все случаи, когда указатель прячется внутри C++-структуры. Прогоняйте сборку с cgocheck в агрессивном режиме на тестах.

Блокировка потока и паники

Пока горутина сидит в блокирующем C++-вызове, она занимает системный поток целиком. Много одновременных долгих cgo-вызовов — и планировщик Go создаёт много потоков ОС, упираясь в лимиты. Ограничивайте параллелизм таких вызовов семафором.

Отдельно: C++-исключение не превращается в Go-панику. Оно просто крашит процесс. Ловите все исключения на C-границе внутри extern "C"-обёртки и возвращайте код ошибки в Go, а не позволяйте исключению пересечь границу.

Сборка и бинарная совместимость

Отдельная категория проблем — не код, а то, чем он собран. C++ ABI не стабилен между компиляторами и иногда между их версиями. Если Python-расширение собрано одним компилятором, а система с другим stdlib — символы не сойдутся в рантайме.

• Собирайте расширение той же цепочкой, что и целевая среда исполнения, или статически линкуйте libstdc++.
• Для Python фиксируйте ABI-тег: расширение под CPython 3.11 не загрузится в 3.12, если вы не используете стабильный ABI.
• Для Go статическая линковка C++-зависимостей упрощает раскатку, но проверьте лицензии линкуемых библиотек.

Сводная таблица решений

Чек-лист перед выкатом

1. Каждый указатель через границу имеет явного владельца и момент освобождения.
2. Долгий C++-код отпускает GIL (Python) или ограничен по параллелизму (Go).
3. Ни одно C++-исключение не пересекает границу неперехваченным.
4. Прогнан тест под конкурентной нагрузкой, а не только однопоточный.
5. Прогон под санитайзерами: AddressSanitizer на C++-части находит use-after-free, который в обычной сборке молчит.
6. Бинарная совместимость: расширение собрано под целевую версию рантайма и ABI.

Что делать дальше

Поставьте на C++-часть непрерывный прогон под AddressSanitizer и UndefinedBehaviorSanitizer в CI — большинство «невоспроизводимых» продакшен-сегфолтов на этой границе они ловят на этапе тестов. В проде мониторьте RSS процесса: медленный рост памяти почти всегда означает неосвобождённый буфер на C-стороне, который не виден профилировщику Python или Go. И держите отдельный дашборд по числу системных потоков для Go-сервисов с cgo — резкий рост сигнализирует, что блокирующие вызовы забили планировщик.