Несколько независимых встроенных интерпретаторов Python в нескольких потоках операционной системы, вызываемых из программы на C / C ++

Question

Встраивание интерпретатора Python в приложение C / C ++ хорошо документировано . Каков наилучший подход для запуска нескольких интерпретаторов Python в нескольких потоках операционной системы (то есть в одном интерпретаторе в одном потоке операционной системы в одном и том же процессе), которые вызываются из приложения C / C ++? Такие приложения могут также иметь проблемы, связанные с фрагментацией памяти и ограничениями Py_Finalize () .

Один из таких подходов может быть следующим:

1. Поток Python и, следовательно, GIL отключены в pyconfig.h для простоты (#undef WITH_THREAD)
2. Все изменяемые глобальные переменные исходного кода Python Interpreter перемещены в структуру, выделенную из кучи, на которую ссылается поток локального хранилища (ссылка: Python на телефоне ).

Мои вопросы:

1. Есть ли лучший подход?
2. Существуют ли какие-либо инструменты, которые могут автоматизировать преобразование глобальных переменных исходного кода Python Interpreter в структуру, выделенную из кучи, на которую ссылается TLS (Thread Local Storage)?

Подобные темы обсуждаются здесь:

• Несколько независимых интерпретаторов Python в программе на C / C ++?
• Несколько интерпретаторов Python в одном процессе
• Lua Versus Python

Answer 1

Это не совсем ответ на ваш вопрос, но вы можете использовать отдельные процессы вместо потоков, тогда проблемы должны исчезнуть.

Плюсы:

• Нет необходимости взламывать Python (и убедиться, что результат работает во всех предполагаемых случаях)
• Вероятно, меньше усилий по разработке в целом
• Простое обновление до новых версий Python
• Четко определенные интерфейсы между различными процессами, что упрощает получение правильных данных и отладку

Минусы:

• Может быть, немного больше веса, в зависимости от вашей платформы ( относительно легкие процессы в Linux )

Если вы используете разделяемую память для IPC, ваш результирующий код приложения не должен сильно отличаться от того, что вы получите с потоками.

Учитывая, что некоторые люди утверждают, что вы всегда должны использовать процессы над потоками , я бы, по крайней мере, рассмотрел его как альтернативу, если он как-то соответствует вашим ограничениям.