Содержание страницы
Инициализация, финализация и потоки¶Initialization, Finalization, and Threads
Подробнее о том, как настроить интерпретатор до инициализации, см. в Python Initialization Configuration.
Перед инициализацией Python¶Before Python Initialization
В приложении, внедряющем Python, функция Py_Initialize() должна
быть вызвана до использования любых других функций Python/C API; за исключением
нескольких функций и глобальных переменных конфигурации.
Следующие функции можно безопасно вызывать до инициализации Python:
Функции, инициализирующие интерпретатор:
функции предварительной инициализации среды выполнения, описанные в Python Initialization Configuration
Функции конфигурации:
PyInitFrozenExtensions()функции конфигурации, описанные в Python Initialization Configuration
Информационные функции:
Утилиты:
функции сообщения о состоянии и утилиты, описанные в Python Initialization Configuration
Распределители памяти:
Синхронизация:
Примечание
Несмотря на внешнее сходство с некоторыми из перечисленных выше функций,
следующие функции не должны вызываться до инициализации
интерпретатора: Py_EncodeLocale(), Py_GetPath(),
Py_GetPrefix(), Py_GetExecPrefix(),
Py_GetProgramFullPath(), Py_GetPythonHome(),
Py_GetProgramName(), PyEval_InitThreads() и
Py_RunMain().
Глобальные переменные конфигурации¶Global configuration variables
В Python есть переменные глобальной конфигурации, управляющие различными возможностями и настройками. По умолчанию эти флаги задаются параметрами командной строки.
Когда флаг устанавливается через параметр, значение флага равно количеству раз, которое этот параметр был указан. Например, -b устанавливает Py_BytesWarningFlag в 1, а -bb устанавливает Py_BytesWarningFlag в 2.
-
int Py_BytesWarningFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.bytes_warning. См. Python Initialization Configuration.Выдавать предупреждение при сравнении
bytesилиbytearrayсstrилиbytesсint. Если значение больше или равно2, выдавать ошибку.Устанавливается опцией
-b.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_DebugFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.parser_debug. См. Python Initialization Configuration.Включает отладочный вывод парсера (только для экспертов, зависит от опций компиляции).
Устанавливается опцией
-dи переменной окруженияPYTHONDEBUG.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_DontWriteBytecodeFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.write_bytecode. См. Python Initialization Configuration.Если установлено ненулевое значение, Python не будет пытаться записывать файлы
.pycпри импорте исходных модулей.Устанавливается опцией
-Bи переменной окруженияPYTHONDONTWRITEBYTECODE.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_FrozenFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.pathconfig_warnings; см. Python Initialization Configuration.Подавляет сообщения об ошибках при вычислении пути поиска модулей в
Py_GetPath().Внутренний флаг, используемый программами
_freeze_moduleиfrozenmain.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_HashRandomizationFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.hash_seedиPyConfig.use_hash_seed; см. конфигурацию инициализации Python.Устанавливается в
1, если переменная окруженияPYTHONHASHSEEDустановлена в непустую строку.Если флаг ненулевой, читает переменную окружения
PYTHONHASHSEEDдля инициализации секретного начального значения хеша.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_IgnoreEnvironmentFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.use_environment; см. Python Initialization Configuration.Игнорировать все переменные окружения
PYTHON*, напримерPYTHONPATHиPYTHONHOME, которые могли быть установлены.Устанавливается параметрами
-Eи-I.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_InspectFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.inspect; см. Python Initialization Configuration.Если скрипт передан первым аргументом или используется параметр
-c, после выполнения скрипта или команды перейти в интерактивный режим, даже еслиsys.stdinне является терминалом.Устанавливается опцией
-iи переменной окруженияPYTHONINSPECT.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_InteractiveFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.interactive; см. Python Initialization Configuration.Устанавливается опцией
-i.Устарело с версии 3.12, будет удалено в версии 3.15.
-
int Py_IsolatedFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.isolated; см. Python Initialization Configuration.Запуск Python в изолированном режиме. В изолированном режиме
sys.pathне содержит ни каталог скрипта, ни каталог site-packages пользователя.Устанавливается опцией
-I.Добавлено в версии 3.4.
Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_LegacyWindowsFSEncodingFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyPreConfig.legacy_windows_fs_encoding; см. Python Initialization Configuration.Если флаг ненулевой, используется кодировка
mbcsс обработчиком ошибокreplaceвместо кодировки UTF-8 с обработчиком ошибокsurrogatepassдля кодировки файловой системы и обработчика ошибок.Устанавливается в
1, если переменная окруженияPYTHONLEGACYWINDOWSFSENCODINGустановлена в непустую строку.См. PEP 529 для подробностей.
Доступность: Windows.
Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_LegacyWindowsStdioFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.legacy_windows_stdio; см. Python Initialization Configuration.Если флаг ненулевой, используется
io.FileIOвместоio._WindowsConsoleIOдляsysстандартных потоков.Устанавливается в
1, если переменная окруженияPYTHONLEGACYWINDOWSSTDIOустановлена в непустую строку.См. PEP 528 для подробностей.
Доступность: Windows.
Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_NoSiteFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.site_import; см. Python Initialization Configuration.Отключает импорт модуля
siteи связанные с ним site-зависимые манипуляции сsys.path. Также отключает эти манипуляции, еслиsiteявно импортирован позже (для их выполнения следует вызватьsite.main()).Устанавливается опцией
-S.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_NoUserSiteDirectory¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.user_site_directory; см. Python Initialization Configuration.Не добавляет
user site-packages directoryвsys.path.Устанавливается параметрами
-sи-I, а также переменной окруженияPYTHONNOUSERSITE.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_OptimizeFlag¶
Этот API сохранён для обратной совместимости: следует использовать настройку
PyConfig.optimization_level; см. Python Initialization Configuration.Устанавливается опцией
-Oи переменной окруженияPYTHONOPTIMIZE.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_QuietFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.quiet. См. Python Initialization Configuration.Не выводить сообщения об авторских правах и версии, даже в интерактивном режиме.
Устанавливается опцией
-q.Добавлено в версии 3.2.
Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_UnbufferedStdioFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.buffered_stdio. См. Python Initialization Configuration.Принудительно отключает буферизацию потоков stdout и stderr.
Устанавливается опцией
-uи переменной окруженияPYTHONUNBUFFERED.Устарело с версии 3.12, будет удалено в версии 3.14.
-
int Py_VerboseFlag¶
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.verbose. См. Python Initialization Configuration.Выводит сообщение каждый раз при инициализации модуля, указывая, откуда он загружается (имя файла или встроенный модуль). Если значение больше или равно
2, выводит сообщение для каждого файла, который проверяется при поиске модуля. Также предоставляет информацию об очистке модулей при завершении работы.Устанавливается опцией
-vи переменной окруженияPYTHONVERBOSE.Устарело с версии 3.12, будет удалено в версии 3.14.
Инициализация и завершение работы интерпретатора¶Initializing and finalizing the interpreter
-
void Py_Initialize()¶
- Часть Stable ABI.
Инициализирует интерпретатор Python. В приложении, встраивающем Python, эту функцию следует вызывать до использования любых других функций Python/C API; за несколькими исключениями обращайтесь к Before Python Initialization.
Эта функция инициализирует таблицу загруженных модулей (
sys.modules) и создаёт фундаментальные модулиbuiltins,__main__иsys. Также она инициализирует путь поиска модулей (sys.path). Она не устанавливаетsys.argv; для этого следует использовать API Python Initialization Configuration. При повторном вызове (без предварительного вызоваPy_FinalizeEx()) функция ничего не делает. Возвращаемого значения нет; если инициализация завершается ошибкой, это фатальная ошибка.Используйте
Py_InitializeFromConfig()для настройки конфигурации инициализации Python.Примечание
В Windows изменяет режим консоли с
O_TEXTнаO_BINARY, что также влияет на использование консоли не из Python через среду выполнения C.
-
void Py_InitializeEx(int initsigs)¶
- Часть Stable ABI.
Эта функция работает как
Py_Initialize(), если initsigs равно1. Если initsigs равно0, она пропускает начальную регистрацию обработчиков сигналов, что может быть полезно, когда CPython встраивается в более крупное приложение.Используйте
Py_InitializeFromConfig()для настройки конфигурации инициализации Python.
-
PyStatus Py_InitializeFromConfig(const PyConfig *config)¶
Инициализирует Python из конфигурации config, как описано в Initialization with PyConfig.
Подробнее о предварительной инициализации интерпретатора, заполнении структуры конфигурации времени выполнения и проверке возвращаемой структуры состояния см. в разделе Python Initialization Configuration.
-
int Py_IsInitialized()¶
- Часть Stable ABI.
Возвращает true (ненулевое значение), если интерпретатор Python был инициализирован, и false (ноль), если нет. После вызова
Py_FinalizeEx()функция возвращает false до тех пор, пока не будет снова вызванаPy_Initialize().
-
int Py_IsFinalizing()¶
- Часть Stable ABI, начиная с версии 3.13.
Возвращает истину (не ноль), если главный интерпретатор Python завершает работу. В противном случае возвращает ложь (ноль).
Добавлено в версии 3.13.
-
int Py_FinalizeEx()¶
- Часть Stable ABI начиная с версии 3.6.
Отменяет всю инициализацию, выполненную с помощью
Py_Initialize(), и последующее использование функций Python/C API, а также уничтожает все под-интерпретаторы (см.Py_NewInterpreter()ниже), которые были созданы и ещё не уничтожены после последнего вызоваPy_Initialize(). В идеале это освобождает всю память, выделенную интерпретатором Python. При повторном вызове (без предварительного вызоваPy_Initialize()сначала) эта функция ничего не делает.Поскольку эта функция является обратной по отношению к
Py_Initialize(), её следует вызывать в том же потоке с тем же активным интерпретатором. Это означает главный поток и главный интерпретатор. Никогда не следует вызывать её во время работыPy_RunMain().Обычно возвращаемое значение –
0. Если во время завершения (сброса буферизованных данных) произошли ошибки, возвращается-1.Эта функция предусмотрена по ряду причин. Встраивающее приложение может захотеть перезапустить Python без перезапуска самого приложения. Приложение, загрузившее интерпретатор Python из динамически загружаемой библиотеки (или DLL), может захотеть освободить всю память, выделенную Python, перед выгрузкой DLL. В процессе поиска утечек памяти в приложении разработчик может захотеть освободить всю память, выделенную Python, перед выходом из приложения.
Ошибки и предостережения: Уничтожение модулей и объектов в модулях происходит в случайном порядке; это может привести к сбою деструкторов (методов
__del__()), когда они зависят от других объектов (даже функций) или модулей. Динамически загружаемые модули расширений, загруженные Python, не выгружаются. Небольшие объёмы памяти, выделенные интерпретатором Python, могут не освободиться (если вы обнаружили утечку, пожалуйста, сообщите о ней). Память, занятая циклическими ссылками между объектами, не освобождается. Некоторая память, выделенная модулями расширений, может не освободиться. Некоторые расширения могут работать некорректно, если их функция инициализации вызывается более одного раза; это может произойти, если приложение вызываетPy_Initialize()иPy_FinalizeEx()более одного раза.Py_FinalizeEx()не должна вызываться рекурсивно из самой себя. Поэтому она не должна вызываться любым кодом, который может выполняться как часть процесса завершения работы интерпретатора, например обработчикамиatexit, финализаторами объектов или любым кодом, который может выполняться при сбросе файлов stdout и stderr.Возбуждает событие аудита
cpython._PySys_ClearAuditHooksбез аргументов.Добавлено в версии 3.6.
-
void Py_Finalize()¶
- Часть Stable ABI.
Это обратно совместимая версия
Py_FinalizeEx(), которая игнорирует возвращаемое значение.
-
int Py_BytesMain(int argc, char **argv)¶
- Часть Stable ABI с версии 3.8.
Аналогично
Py_Main(), но argv является массивом строк байтов, что позволяет вызывающему приложению делегировать этап декодирования текста среде выполнения CPython.Добавлено в версии 3.8.
-
int Py_Main(int argc, wchar_t **argv)¶
- Часть Stable ABI.
Главная программа стандартного интерпретатора, инкапсулирующая полный цикл инициализации/завершения, а также дополнительное поведение для реализации чтения параметров конфигурации из окружения и командной строки, и затем выполнения
__main__в соответствии с командной строкой.Эта функция доступна для программ, которые хотят поддерживать полный интерфейс командной строки CPython, а не просто встраивать среду выполнения Python в более крупное приложение.
Параметры argc и argv аналогичны тем, которые передаются функции
main()программы на C, за исключением того, что элементы argv сначала преобразуются вwchar_tс помощьюPy_DecodeLocale(). Также важно отметить, что записи списка аргументов могут быть изменены так, чтобы указывать на строки, отличные от переданных (однако содержимое строк, на которые указывает список аргументов, не изменяется).Возвращаемое значение –
2, если список аргументов не представляет собой допустимую командную строку Python, и в противном случае то же, что иPy_RunMain().С точки зрения API конфигурации среды выполнения CPython, описанных в разделе runtime configuration (и без учёта обработки ошибок),
Py_Mainпримерно эквивалентно:PyConfig config; PyConfig_InitPythonConfig(&config); PyConfig_SetArgv(&config, argc, argv); Py_InitializeFromConfig(&config); PyConfig_Clear(&config); Py_RunMain();
В обычном использовании встраивающее приложение будет вызывать эту функцию вместо прямого вызова
Py_Initialize(),Py_InitializeEx()илиPy_InitializeFromConfig(), и все настройки будут применены так, как описано в других разделах этой документации. Если эта функция вызывается после предыдущего вызова API инициализации среды выполнения, то то, какие именно настройки окружения и командной строки будут обновлены, зависит от версии (поскольку зависит от того, какие настройки корректно поддерживают изменение после того, как они были установлены один раз при первой инициализации среды выполнения).
-
int Py_RunMain(void)¶
Выполняет главный модуль в полностью сконфигурированной среде выполнения CPython.
Выполняет команду (
PyConfig.run_command), скрипт (PyConfig.run_filename) или модуль (PyConfig.run_module), указанные в командной строке или в конфигурации. Если ни одно из этих значений не задано, запускает интерактивный промпт Python (REPL) с использованием глобального пространства имён модуля__main__.Если
PyConfig.inspectне задан (по умолчанию), возвращаемое значение будет0, если интерпретатор завершается нормально (то есть без возбуждения исключения), кодом выхода необработанногоSystemExit, или1для любого другого необработанного исключения.Если
PyConfig.inspectзадан (например, когда используется опция-i), то вместо возврата при завершении интерпретатора выполнение продолжается в интерактивном промпте Python (REPL) с использованием глобального пространства имён модуля__main__. Если интерпретатор завершился с исключением, это исключение немедленно возбуждается в сессии REPL. Возвращаемое значение функции затем определяется способом завершения сессии REPL:0,1или статусомSystemExit, как указано выше.Эта функция всегда завершает работу интерпретатора Python перед возвратом.
См. Конфигурация Python для примера пользовательской сборки Python, которая всегда работает в изолированном режиме с использованием
Py_RunMain().
-
int PyUnstable_AtExit(PyInterpreterState *interp, void (*func)(void*), void *data)¶
- Это нестабильное API. Оно может меняться без предупреждения в минорных версиях.
Регистрирует колбэк
atexitдля целевого интерпретатора interp. Это аналогичноPy_AtExit(), но принимает явный указатель на интерпретатор и данные для колбэка.GIL должна удерживаться для interp.
Добавлено в версии 3.13.
Общепроцессные параметры¶Process-wide parameters
-
void Py_SetProgramName(const wchar_t *name)¶
- Часть Stable ABI.
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.program_name. См. Python Initialization Configuration.Эту функцию следует вызвать до первого вызова
Py_Initialize(), если она вообще вызывается. Она сообщает интерпретатору значение аргументаargv[0]функцииmain()программы (преобразованное в широкие символы). Это используетсяPy_GetPath()и некоторыми другими функциями ниже для поиска библиотек времени выполнения Python относительно исполняемого файла интерпретатора. Значение по умолчанию –'python'. Аргумент должен указывать на строку широких символов, завершающуюся нулём, в статической памяти, содержимое которой не изменится за время выполнения программы. Никакой код в интерпретаторе Python не изменит содержимое этой памяти.Используйте
Py_DecodeLocale()для декодирования строки байтов, чтобы получить строку wchar_t*.Устарело с версии 3.11.
-
wchar_t *Py_GetProgramName()¶
- Часть Stable ABI.
Возвращает имя программы, установленное с помощью
PyConfig.program_name, или значение по умолчанию. Возвращаемая строка указывает на статическую память; вызывающий не должен изменять её значение.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте
sys.executable.
-
wchar_t *Py_GetPrefix()¶
- Часть Stable ABI.
Возвращает префикс для установленных платформонезависимых файлов. Он определяется по ряду сложных правил из имени программы, установленного с помощью
PyConfig.program_name, и некоторых переменных окружения; например, если имя программы –'/usr/local/bin/python', префикс –'/usr/local'. Возвращаемая строка указывает на статическую память; вызывающий не должен изменять её значение. Это соответствует переменной prefix в корневомMakefileи аргументу--prefixсценария configure во время сборки. Значение доступно в коде Python какsys.base_prefix. Полезен только в Unix. Смотрите также следующую функцию.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте
sys.base_prefix, илиsys.prefix, если нужно обрабатывать виртуальные окружения.
-
wchar_t *Py_GetExecPrefix()¶
- Часть Stable ABI.
Возвращает exec-prefix для установленных зависящих от платформы файлов. Значение вычисляется по ряду сложных правил на основе имени программы, заданного с помощью
PyConfig.program_name, и некоторых переменных окружения; например, если имя программы –'/usr/local/bin/python', то exec-prefix будет'/usr/local'. Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Это соответствует переменной exec_prefix вMakefileи аргументу--exec-prefixскрипта configure на этапе сборки. Значение доступно в коде Python какsys.base_exec_prefix. Это имеет смысл только в Unix.Контекст: exec-prefix отличается от префикса (prefix), когда зависящие от платформы файлы (например, исполняемые файлы и динамические библиотеки) устанавливаются в другое дерево каталогов. В типичной установке платформенно-зависимые файлы могут быть установлены в поддерево
/usr/local/plat, а платформенно-независимые – в/usr/local.Вообще говоря, платформа – это комбинация семейств аппаратного и программного обеспечения; например, машины Sparc под управлением ОС Solaris 2.x считаются одной платформой, машины Intel под Solaris 2.x – другой, а машины Intel под Linux – третьей. Разные основные версии одной и той же ОС обычно также образуют разные платформы. Операционные системы, отличные от Unix, – это отдельная история; стратегии установки на этих системах настолько различаются, что префикс и exec-prefix не имеют смысла и устанавливаются в пустую строку. Обратите внимание: скомпилированные файлы байт-кода Python не зависят от платформы (но не от версии Python, под которой они были скомпилированы!).
Системные администраторы знают, как настроить программы mount или automount для совместного использования
/usr/localмежду платформами, при этом/usr/local/platбудет отдельной файловой системой для каждой платформы.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте
sys.base_exec_prefix, илиsys.exec_prefix, если нужно обрабатывать виртуальные окружения.
-
wchar_t *Py_GetProgramFullPath()¶
- Часть Stable ABI.
Возвращает полное имя программы исполняемого файла Python; оно вычисляется как побочный эффект при получении пути поиска модулей по умолчанию из имени программы (заданного с помощью
PyConfig.program_name). Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Значение доступно в коде Python какsys.executable.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте
sys.executable.
-
wchar_t *Py_GetPath()¶
- Часть Stable ABI.
Возвращает путь поиска модулей по умолчанию; он вычисляется из имени программы (заданного с помощью
PyConfig.program_name) и некоторых переменных окружения. Возвращаемая строка состоит из последовательности имён каталогов, разделённых символом-разделителем, зависящим от платформы. Символ-разделитель –':'в Unix и macOS,';'в Windows. Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Списокsys.pathинициализируется этим значением при запуске интерпретатора; позже его можно (и обычно так и делается) изменить для настройки пути поиска модулей.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте
sys.path.
-
const char *Py_GetVersion()¶
- Часть Stable ABI.
Возвращает версию данного интерпретатора Python. Это строка, которая выглядит примерно так:
"3.0a5+ (py3k:63103M, May 12 2008, 00:53:55) \n[GCC 4.2.3]"
Первое слово (до первого пробела) – это текущая версия Python; первые символы – это мажорная и минорная версии, разделённые точкой. Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Это значение доступно в коде Python как
sys.version.Смотрите также константу
Py_Version.
-
const char *Py_GetPlatform()¶
- Часть Stable ABI.
Возвращает идентификатор платформы для текущей платформы. В Unix он формируется из «официального» имени операционной системы, преобразованного в нижний регистр, за которым следует номер основной ревизии; например, для Solaris 2.x, также известного как SunOS 5.x, значение –
'sunos5'. В macOS –'darwin'. В Windows –'win'. Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Значение доступно в коде Python какsys.platform.
-
const char *Py_GetCopyright()¶
- Часть Stable ABI.
Возвращает официальную строку авторских прав для текущей версии Python, например
'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Значение доступно в коде Python как
sys.copyright.
-
const char *Py_GetCompiler()¶
- Часть Stable ABI.
Возвращает указание компилятора, использованного для сборки текущей версии Python, в квадратных скобках, например:
"[GCC 2.7.2.2]"Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Значение доступно коду Python как часть переменной
sys.version.
-
const char *Py_GetBuildInfo()¶
- Часть Stable ABI.
Возвращает информацию о номере сборки, дате и времени сборки текущего экземпляра интерпретатора Python, например
"#67, Aug 1 1997, 22:34:28"Возвращаемая строка указывает на статическую память; вызывающий код не должен изменять её значение. Значение доступно коду Python как часть переменной
sys.version.
-
void PySys_SetArgvEx(int argc, wchar_t **argv, int updatepath)¶
- Часть Stable ABI.
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.argv,PyConfig.parse_argvиPyConfig.safe_path. См. Python Initialization Configuration.Устанавливает
sys.argvна основе argc и argv. Эти параметры похожи на передаваемые функцииmain()программы, с тем отличием, что первый элемент должен указывать на исполняемый файл сценария, а не на исполняемый файл, в котором работает интерпретатор Python. Если запускаемый сценарий отсутствует, первый элемент в argv может быть пустой строкой. Если этой функции не удаётся инициализироватьsys.argv, фатальная ситуация сигнализируется с помощьюPy_FatalError().Если updatepath равен нулю, на этом работа функции заканчивается. Если updatepath не равен нулю, функция также изменяет
sys.pathпо следующему алгоритму:Если в
argv[0]передано имя существующего сценария, то абсолютный путь к каталогу, в котором находится сценарий, добавляется в началоsys.path.В противном случае (то есть если argc равен
0илиargv[0]не указывает на существующее имя файла), пустая строка добавляется в началоsys.path, что эквивалентно добавлению текущего рабочего каталога (".").
Используйте
Py_DecodeLocale()для декодирования строки байтов, чтобы получить строку wchar_t*.См. также члены
PyConfig.orig_argvиPyConfig.argvструктуры Python Initialization Configuration.Примечание
Приложениям, встраивающим интерпретатор Python не для выполнения одного сценария, рекомендуется передавать
0в качестве updatepath и при желании обновлятьsys.pathсамостоятельно. См. CVE 2008-5983.В версиях до 3.1.3 того же эффекта можно достичь, вручную удалив первый элемент
sys.pathпосле вызоваPySys_SetArgv(), например используя:PyRun_SimpleString("import sys; sys.path.pop(0)\n");
Добавлено в версии 3.1.3.
Устарело с версии 3.11.
-
void PySys_SetArgv(int argc, wchar_t **argv)¶
- Часть Stable ABI.
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.argvиPyConfig.parse_argv. См. Python Initialization Configuration.Эта функция работает как
PySys_SetArgvEx()с updatepath, установленным в1, если только интерпретатор python не был запущен с-I.Используйте
Py_DecodeLocale()для декодирования строки байтов, чтобы получить строку wchar_t*.См. также члены
PyConfig.orig_argvиPyConfig.argvструктуры Python Initialization Configuration.Изменено в версии 3.4: Значение updatepath зависит от
-I.Устарело с версии 3.11.
-
void Py_SetPythonHome(const wchar_t *home)¶
- Часть Stable ABI.
Этот API сохранён для обратной совместимости: вместо него следует использовать
PyConfig.home. См. Python Initialization Configuration.Устанавливает домашний каталог по умолчанию, то есть расположение стандартных библиотек Python. См.
PYTHONHOMEдля пояснения значения строки аргумента.Аргумент должен указывать на строку символов, завершающуюся нулём, в статической памяти, содержимое которой не будет изменяться в течение всего времени выполнения программы. Никакой код в интерпретаторе Python не будет менять содержимое этой памяти.
Используйте
Py_DecodeLocale()для декодирования строки байтов, чтобы получить строку wchar_t*.Устарело с версии 3.11.
-
wchar_t *Py_GetPythonHome()¶
- Часть Stable ABI.
Возвращает «домашний» каталог по умолчанию, то есть значение, установленное с помощью
PyConfig.home, или значение переменной окруженияPYTHONHOME, если она задана.Эту функцию не следует вызывать до
Py_Initialize(), иначе она возвращаетNULL.Изменено в версии 3.10: Теперь возвращает
NULL, если вызвано доPy_Initialize().Устарело с версии 3.13, будет удалено в версии 3.15: Вместо этого используйте переменную окружения
PyConfig.homeилиPYTHONHOME.
Состояние потока и глобальная блокировка интерпретатора¶Thread State and the Global Interpreter Lock
Интерпретатор Python не является полностью потокобезопасным. Для поддержки многопоточных программ на Python существует глобальная блокировка, называемая глобальной блокировкой интерпретатора или GIL, которую текущий поток должен удерживать перед тем, как безопасно обращаться к объектам Python. Без этой блокировки даже простейшие операции могут вызывать проблемы в многопоточной программе: например, когда два потока одновременно увеличивают счётчик ссылок одного и того же объекта, счётчик может в итоге увеличиться только один раз вместо двух.
Поэтому существует правило: только поток, захвативший GIL, может работать с объектами Python или вызывать функции Python/C API. Для эмуляции параллелизма выполнения интерпретатор регулярно пытается переключать потоки (см. sys.setswitchinterval()). Блокировка также освобождается вокруг потенциально блокирующих операций ввода-вывода, таких как чтение или запись файла, чтобы тем временем могли работать другие потоки Python.
Интерпретатор Python хранит некоторую служебную информацию, специфичную для потока, в структуре данных, называемой PyThreadState. Существует также одна глобальная переменная, указывающая на текущий PyThreadState: её можно получить с помощью PyThreadState_Get().
Освобождение GIL из кода расширения¶Releasing the GIL from extension code
Большая часть кода расширения, работающего с GIL, имеет следующую простую структуру:
Save the thread state in a local variable.
Release the global interpreter lock.
... Do some blocking I/O operation ...
Reacquire the global interpreter lock.
Restore the thread state from the local variable.
Это настолько распространено, что существует пара макросов для упрощения:
Py_BEGIN_ALLOW_THREADS
... Do some blocking I/O operation ...
Py_END_ALLOW_THREADS
Макрос Py_BEGIN_ALLOW_THREADS открывает новый блок и объявляет скрытую локальную переменную; макрос Py_END_ALLOW_THREADS закрывает блок.
Приведённый выше блок раскрывается в следующий код:
PyThreadState *_save;
_save = PyEval_SaveThread();
... Do some blocking I/O operation ...
PyEval_RestoreThread(_save);
Вот как работают эти функции: глобальная блокировка интерпретатора используется для защиты указателя на текущее состояние потока. При освобождении блокировки и сохранении состояния потока указатель на текущее состояние потока должен быть получен до освобождения блокировки (поскольку другой поток может немедленно захватить блокировку и сохранить своё состояние потока в глобальной переменной). И наоборот, при захвате блокировки и восстановлении состояния потока блокировка должна быть захвачена до сохранения указателя на состояние потока.
Примечание
Вызов системных функций ввода-вывода – это наиболее распространённый случай освобождения GIL, но он также может быть полезен перед вызовом длительных вычислений, не требующих доступа к объектам Python, таких как функции сжатия или шифрования, работающие с буферами памяти. Например, стандартные модули zlib и hashlib освобождают GIL при сжатии или хешировании данных.
Потоки, созданные не из Python¶Non-Python created threads
Когда потоки создаются с помощью специализированных Python API (например, модуля threading), с ними автоматически связывается состояние потока, и приведённый выше код корректен. Однако, когда потоки создаются из C (например, сторонней библиотекой с собственным управлением потоками), они не удерживают GIL и для них не существует структуры состояния потока.
Если необходимо вызвать код Python из этих потоков (часто это будет частью API колбэков, предоставляемого упомянутой сторонней библиотекой), сначала нужно зарегистрировать эти потоки в интерпретаторе, создав структуру данных состояния потока, затем захватить GIL и, наконец, сохранить указатель на их состояние потока, прежде чем можно будет начать использовать Python/C API. После завершения следует сбросить указатель состояния потока, освободить GIL и освободить структуру данных состояния потока.
Функции PyGILState_Ensure() и PyGILState_Release() делают всё вышеописанное автоматически. Типичный способ вызова Python из потока C:
PyGILState_STATE gstate;
gstate = PyGILState_Ensure();
/* Выполнить действия Python здесь. */
result = CallSomeFunction();
/* вычислить результат или обработать исключение */
/* Освободить поток. После этой точки API Python не допускается. */
PyGILState_Release(gstate);
Обратите внимание, что функции PyGILState_* предполагают наличие только одного глобального интерпретатора (создаваемого автоматически с помощью Py_Initialize()). Python поддерживает создание дополнительных интерпретаторов (с помощью Py_NewInterpreter()), но смешивание нескольких интерпретаторов и API PyGILState_* не поддерживается.
Предостережения относительно fork()¶Cautions about fork()
Ещё одна важная особенность потоков – их поведение при вызове C fork(). На большинстве систем с fork() после
fork процесса остаётся только тот поток, который вызвал fork. Это
оказывает конкретное влияние как на обработку блокировок, так и на всё сохранённое состояние
в среде выполнения CPython.
Тот факт, что остаётся только «текущий» поток, означает, что любые блокировки, удерживаемые другими потоками, никогда не будут освобождены. Python решает эту проблему для os.fork(), захватывая блокировки, которые он использует внутренне, перед fork и освобождая их после. Кроме того, он сбрасывает все
объекты блокировки в дочернем процессе. При расширении или встраивании Python нет способа сообщить Python о дополнительных (не-Python) блокировках, которые необходимо захватить перед fork или сбросить после него. Для достижения того же эффекта потребуется использовать системные механизмы, такие как
pthread_atfork().
Кроме того, при расширении или встраивании Python вызов fork() напрямую, а не через os.fork() (и возврат к вызову Python) может привести к взаимоблокировке из-за того, что одна из внутренних блокировок Python удерживается потоком, который становится недействительным после fork.
PyOS_AfterFork_Child() пытается сбросить необходимые блокировки, но не всегда может это сделать.
Тот факт, что все остальные потоки исчезают, также означает, что состояние среды выполнения CPython должно быть правильно очищено, что и делает os.fork(). Это означает завершение всех остальных объектов PyThreadState, принадлежащих текущему интерпретатору, и всех остальных объектов PyInterpreterState. Из-за этого и особой природы «главного» интерпретатора, fork() следует вызывать только в «главном» потоке этого интерпретатора, где изначально была инициализирована глобальная среда выполнения CPython. Единственное исключение – если exec() будет вызван сразу после.
Предостережения по поводу финализации среды выполнения¶Cautions regarding runtime finalization
На позднем этапе завершения работы интерпретатора, после попытки дождаться завершения
нефоновых потоков (хотя это может быть прервано KeyboardInterrupt) и выполнения функций atexit, среда выполнения
помечается как финализируемая: Py_IsFinalizing() и
sys.is_finalizing() возвращают true. На этот момент только поток финализации, который инициировал финализацию (обычно главный поток), может
захватить GIL.
Если какой-либо поток, кроме потока финализации, пытается захватить GIL во время финализации, явно через PyGILState_Ensure(), Py_END_ALLOW_THREADS, PyEval_AcquireThread() или PyEval_AcquireLock(), или неявно, когда интерпретатор пытается перезахватить его после того, как отдал, поток переходит в состояние постоянной блокировки, в котором остаётся до завершения программы. В большинстве случаев это безвредно, но может привести к взаимоблокировке, если более поздний этап финализации попытается захватить блокировку, принадлежащую заблокированному потоку, или иным образом ожидает заблокированный поток.
Грубо? Да. Это предотвращает случайные крахи и/или неожиданный пропуск финализаций C++ выше по стеку вызовов, когда такие потоки принудительно завершались здесь в CPython 3.13.7 и более ранних версиях. C API среды выполнения CPython для захвата GIL никогда не имели ожиданий по сообщению об ошибках или их обработке во время захвата GIL, что позволило бы корректно выйти из этой ситуации. Изменение этого потребовало бы новых стабильных C API и переписывания большей части кода C в экосистеме CPython для их использования с обработкой ошибок.
API высокого уровня¶High-level API
Это наиболее часто используемые типы и функции при написании кода C-расширения или при встраивании интерпретатора Python:
-
type PyInterpreterState¶
- Часть Limited API (как непрозрачная структура).
Эта структура данных представляет состояние, совместно используемое несколькими взаимодействующими потоками. Потоки, принадлежащие одному интерпретатору, разделяют администрирование модулей и несколько других внутренних элементов. В этой структуре нет открытых членов.
Потоки, принадлежащие разным интерпретаторам, изначально не разделяют ничего, кроме состояния процесса, такого как доступная память, открытые файловые дескрипторы и т.п. Глобальная блокировка интерпретатора также разделяется всеми потоками, независимо от того, какому интерпретатору они принадлежат.
Изменено в версии 3.12: PEP 684 ввёл возможность индивидуального GIL для каждого интерпретатора. См.
Py_NewInterpreterFromConfig().
-
type PyThreadState¶
- Часть Limited API (как непрозрачная структура).
Эта структура данных представляет состояние одного потока. Единственный открытый элемент данных:
-
PyInterpreterState *interp¶
Состояние интерпретатора этого потока.
-
PyInterpreterState *interp¶
-
void PyEval_InitThreads()¶
- Часть Stable ABI.
Устаревшая функция, которая ничего не делает.
В Python 3.6 и старше эта функция создавала GIL, если его не существовало.
Изменено в версии 3.9: Теперь функция ничего не делает.
Изменено в версии 3.7: Теперь эта функция вызывается
Py_Initialize(), так что вам больше не нужно вызывать её самостоятельно.Изменено в версии 3.2: Эту функцию больше нельзя вызывать до
Py_Initialize().Устарело с версии 3.9.
-
PyThreadState *PyEval_SaveThread()¶
- Часть Stable ABI.
Освобождает глобальную блокировку интерпретатора (если она была создана) и сбрасывает состояние потока на
NULL, возвращая предыдущее состояние потока (которое не равноNULL). Если блокировка была создана, текущий поток должен был её захватить.
-
void PyEval_RestoreThread(PyThreadState *tstate)¶
- Часть Stable ABI.
Захватывает глобальную блокировку интерпретатора (если она была создана) и устанавливает состояние потока в tstate, которое не должно быть
NULL. Если блокировка была создана, текущий поток не должен был её захватить, иначе возникает взаимоблокировка.Примечание
Вызов этой функции из потока, когда среда выполнения завершается, приведёт к зависанию потока до выхода из программы, даже если поток не был создан Python. Подробнее см. в Предостережения относительно завершения работы среды выполнения.
Изменено в версии 3.13.8: Приостанавливает текущий поток, а не завершает его, если вызвано во время финализации интерпретатора.
-
PyThreadState *PyThreadState_Get()¶
- Часть Stable ABI.
Возвращает текущее состояние потока. Глобальная блокировка интерпретатора должна быть захвачена. Если текущее состояние потока равно
NULL, вызывается фатальная ошибка (так что вызывающему коду не нужно проверять наNULL).См. также
PyThreadState_GetUnchecked().
-
PyThreadState *PyThreadState_GetUnchecked()¶
Аналогично
PyThreadState_Get(), но не завершает процесс фатальной ошибкой, если значение равно NULL. Вызывающий код должен самостоятельно проверить, не является ли результат NULL.Добавлено в версии 3.13: В версиях Python с 3.5 по 3.12 эта функция была приватной и называлась
_PyThreadState_UncheckedGet().
-
PyThreadState *PyThreadState_Swap(PyThreadState *tstate)¶
- Часть Stable ABI.
Заменяет текущее состояние потока на состояние потока, заданное аргументом tstate, который может быть
NULL.Удерживать GIL не требуется, но он будет удерживаться при возврате, если tstate не равен
NULL.
Следующие функции используют локальное хранилище потока и несовместимы с подынтерпретаторами:
-
type PyGILState_STATE¶
- Часть Stable ABI.
Тип значения, возвращаемого
PyGILState_Ensure()и передаваемого вPyGILState_Release().-
enumerator PyGILState_LOCKED¶
GIL уже был захвачен, когда была вызвана
PyGILState_Ensure().
-
enumerator PyGILState_UNLOCKED¶
GIL не был захвачен, когда была вызвана
PyGILState_Ensure().
-
enumerator PyGILState_LOCKED¶
-
PyGILState_STATE PyGILState_Ensure()¶
- Часть Stable ABI.
Обеспечивает, что текущий поток готов к вызову Python C API независимо от текущего состояния Python или глобальной блокировки интерпретатора. Этот вызов может вызываться потоком сколько угодно раз, при условии, что каждый вызов завершается вызовом
PyGILState_Release(). В общем случае другие API, связанные с потоками, могут использоваться между вызовамиPyGILState_Ensure()иPyGILState_Release(), если состояние потока будет восстановлено в предыдущее состояние перед Release(). Например, обычное использование макросовPy_BEGIN_ALLOW_THREADSиPy_END_ALLOW_THREADSдопустимо.Возвращаемое значение – это непрозрачный «дескриптор» состояния потока на момент вызова
PyGILState_Ensure(), и его необходимо передать вPyGILState_Release(), чтобы гарантировать, что Python останется в том же состоянии. Хотя рекурсивные вызовы разрешены, эти дескрипторы нельзя совместно использовать – каждый уникальный вызовPyGILState_Ensure()должен сохранить свой дескриптор для вызоваPyGILState_Release().Когда функция возвращает управление, текущий поток будет удерживать GIL и сможет вызывать произвольный код Python. Сбой является фатальной ошибкой.
Примечание
Вызов этой функции из потока, когда среда выполнения завершается, приведёт к зависанию потока до выхода из программы, даже если поток не был создан Python. Подробнее см. в Предостережения относительно завершения работы среды выполнения.
Изменено в версии 3.13.8: Зависает текущий поток, а не завершает его, если вызывается во время финализации интерпретатора.
-
void PyGILState_Release(PyGILState_STATE)¶
- Часть Stable ABI.
Освобождает любые ресурсы, полученные ранее. После этого вызова состояние Python будет таким же, как до соответствующего вызова
PyGILState_Ensure()(но обычно это состояние неизвестно вызывающему, поэтому используется GILState API).Каждый вызов
PyGILState_Ensure()должен сопровождаться вызовомPyGILState_Release()в том же потоке.
-
PyThreadState *PyGILState_GetThisThreadState()¶
- Часть Stable ABI.
Возвращает состояние текущего потока. Может вернуть
NULL, если на текущем потоке не использовался GILState API. Обратите внимание, что главный поток всегда имеет такое состояние, даже если для него не вызывался auto-thread-state. Это вспомогательная/диагностическая функция.
-
int PyGILState_Check()¶
Возвращает
1, если текущий поток удерживает GIL, и0в противном случае. Эту функцию можно вызывать из любого потока в любое время. Только если состояние потока Python инициализировано и он в данный момент удерживает GIL, она вернёт1. Это в основном вспомогательная/диагностическая функция. Она может быть полезна, например, в контекстах колбэков или функциях выделения памяти, когда знание того, что GIL заблокирован, позволяет вызывающей стороне выполнять чувствительные действия или вести себя иначе.Добавлено в версии 3.4.
Следующие макросы обычно используются без точки с запятой в конце; примеры использования можно найти в дистрибутиве исходного кода Python.
-
Py_BEGIN_ALLOW_THREADS¶
- Часть Stable ABI.
Этот макрос раскрывается в
{ PyThreadState *_save; _save = PyEval_SaveThread();. Обратите внимание, что он содержит открывающую фигурную скобку; она должна быть сопоставлена с последующим макросомPy_END_ALLOW_THREADS. См. выше дополнительное обсуждение этого макроса.
-
Py_END_ALLOW_THREADS¶
- Часть Stable ABI.
Этот макрос раскрывается в
PyEval_RestoreThread(_save); }. Обратите внимание, что он содержит закрывающую фигурную скобку; она должна быть сопоставлена с предыдущим макросомPy_BEGIN_ALLOW_THREADS. См. выше дополнительное обсуждение этого макроса.
-
Py_BLOCK_THREADS¶
- Часть Stable ABI.
Этот макрос разворачивается в
PyEval_RestoreThread(_save);: он эквивалентенPy_END_ALLOW_THREADSбез закрывающей фигурной скобки.
-
Py_UNBLOCK_THREADS¶
- Часть Stable ABI.
Этот макрос разворачивается в
_save = PyEval_SaveThread();: он эквивалентенPy_BEGIN_ALLOW_THREADSбез открывающей фигурной скобки и объявления переменной.
Низкоуровневый API¶Low-level API
Все следующие функции должны вызываться после Py_Initialize().
Изменено в версии 3.7: Py_Initialize() теперь инициализирует GIL.
-
PyInterpreterState *PyInterpreterState_New()¶
- Часть Stable ABI.
Создаёт новый объект состояния интерпретатора. Глобальная блокировка интерпретатора может не удерживаться, но может удерживаться, если необходимо сериализовать вызовы этой функции.
Возбуждает событие аудита
cpython.PyInterpreterState_Newбез аргументов.
-
void PyInterpreterState_Clear(PyInterpreterState *interp)¶
- Часть Stable ABI.
Сбрасывает всю информацию в объекте состояния интерпретатора. Глобальная блокировка интерпретатора должна удерживаться.
Возбуждает событие аудита
cpython.PyInterpreterState_Clearбез аргументов.
-
void PyInterpreterState_Delete(PyInterpreterState *interp)¶
- Часть Stable ABI.
Уничтожает объект состояния интерпретатора. Глобальная блокировка интерпретатора может не удерживаться. Состояние интерпретатора должно быть предварительно сброшено вызовом
PyInterpreterState_Clear().
-
PyThreadState *PyThreadState_New(PyInterpreterState *interp)¶
- Часть Stable ABI.
Создаёт новый объект состояния потока, принадлежащий данному объекту интерпретатора. Глобальная блокировка интерпретатора может не удерживаться, но может удерживаться, если необходимо сериализовать вызовы этой функции.
-
void PyThreadState_Clear(PyThreadState *tstate)¶
- Часть Stable ABI.
Сбрасывает всю информацию в объекте состояния потока. Глобальная блокировка интерпретатора должна удерживаться.
Изменено в версии 3.9: Теперь эта функция вызывает колбэк
PyThreadState.on_delete. Ранее это происходило вPyThreadState_Delete().Изменено в версии 3.13: Колбэк
PyThreadState.on_deleteудалён.
-
void PyThreadState_Delete(PyThreadState *tstate)¶
- Часть Stable ABI.
Уничтожает объект состояния потока. Глобальная блокировка интерпретатора может не удерживаться. Состояние потока должно быть предварительно сброшено вызовом
PyThreadState_Clear().
-
void PyThreadState_DeleteCurrent(void)¶
Уничтожает текущее состояние потока и освобождает глобальную блокировку интерпретатора. Как и
PyThreadState_Delete(), глобальная блокировка интерпретатора должна удерживаться. Состояние потока должно быть предварительно сброшено вызовомPyThreadState_Clear().
-
PyFrameObject *PyThreadState_GetFrame(PyThreadState *tstate)¶
- Часть Stable ABI начиная с версии 3.10.
Возвращает текущий кадр состояния потока Python tstate.
Возвращает сильную ссылку. Возвращает
NULL, если в данный момент кадр не выполняется.См. также
PyEval_GetFrame().tstate не должно быть
NULL.Добавлено в версии 3.9.
-
uint64_t PyThreadState_GetID(PyThreadState *tstate)¶
- Часть Stable ABI начиная с версии 3.10.
Возвращает уникальный идентификатор состояния потока Python для tstate.
tstate не должно быть
NULL.Добавлено в версии 3.9.
-
PyInterpreterState *PyThreadState_GetInterpreter(PyThreadState *tstate)¶
- Часть Stable ABI начиная с версии 3.10.
Возвращает интерпретатор состояния потока Python tstate.
tstate не должно быть
NULL.Добавлено в версии 3.9.
-
void PyThreadState_EnterTracing(PyThreadState *tstate)¶
Приостанавливает трассировку и профилирование в состоянии потока Python tstate.
Возобновляет их с помощью функции
PyThreadState_LeaveTracing().Добавлено в версии 3.12.
-
void PyThreadState_LeaveTracing(PyThreadState *tstate)¶
Возобновляет трассировку и профилирование в состоянии потока Python tstate, приостановленные функцией
PyThreadState_EnterTracing().См. также функции
PyEval_SetTrace()иPyEval_SetProfile().Добавлено в версии 3.12.
-
PyInterpreterState *PyInterpreterState_Get(void)¶
- Часть Stable ABI начиная с версии 3.9.
Получает текущий интерпретатор.
Выдаёт фатальную ошибку, если нет текущего состояния потока Python или текущего интерпретатора. Не может вернуть NULL.
Вызывающий должен удерживать GIL.
Добавлено в версии 3.9.
-
int64_t PyInterpreterState_GetID(PyInterpreterState *interp)¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает уникальный идентификатор интерпретатора. Если при этом произошла ошибка, возвращается
-1и устанавливается исключение.Вызывающий должен удерживать GIL.
Добавлено в версии 3.7.
-
PyObject *PyInterpreterState_GetDict(PyInterpreterState *interp)¶
- Возвращаемое значение: заимствованная ссылка. Часть Stable ABI начиная с версии 3.8.
Возвращает словарь, в котором могут храниться данные, специфичные для интерпретатора. Если эта функция возвращает
NULL, исключение не было возбуждено, и вызывающий код должен считать, что словарь данных интерпретатора недоступен.Это не замена
PyModule_GetState(), который расширения должны использовать для хранения информации о состоянии интерпретатора.Возвращаемый словарь заимствуется из интерпретатора и действителен до завершения работы интерпретатора.
Добавлено в версии 3.8.
-
PyObject *PyUnstable_InterpreterState_GetMainModule(PyInterpreterState *interp)¶
- Это нестабильное API. Оно может меняться без предупреждения в минорных версиях.
Возвращает сильную ссылку на
__main__объект модуля для указанного интерпретатора.Вызывающий должен удерживать GIL.
Добавлено в версии 3.13.
-
typedef PyObject *(*_PyFrameEvalFunction)(PyThreadState *tstate, _PyInterpreterFrame *frame, int throwflag)¶
Тип функции вычисления фрейма.
Параметр throwflag используется методом
throw()генераторов: если он не равен нулю, обрабатывается текущее исключение.Изменено в версии 3.9: Теперь функция принимает параметр tstate.
Изменено в версии 3.11: Параметр frame изменился с
PyFrameObject*на_PyInterpreterFrame*.
-
_PyFrameEvalFunction _PyInterpreterState_GetEvalFrameFunc(PyInterpreterState *interp)¶
Возвращает функцию вычисления фрейма.
См. PEP 523 «Добавление API вычисления фрейма в CPython».
Добавлено в версии 3.9.
-
void _PyInterpreterState_SetEvalFrameFunc(PyInterpreterState *interp, _PyFrameEvalFunction eval_frame)¶
Устанавливает функцию вычисления фрейма.
См. PEP 523 «Добавление API вычисления фрейма в CPython».
Добавлено в версии 3.9.
-
PyObject *PyThreadState_GetDict()¶
- Возвращаемое значение: заимствованная ссылка. Часть Stable ABI.
Возвращает словарь, в котором расширения могут хранить информацию о состоянии, специфичном для потока. Каждое расширение должно использовать уникальный ключ для хранения состояния в словаре. Допускается вызывать эту функцию, когда нет текущего состояния потока. Если эта функция возвращает
NULL, исключение не было возбуждено, и вызывающий должен предполагать, что текущее состояние потока недоступно.
-
int PyThreadState_SetAsyncExc(unsigned long id, PyObject *exc)¶
- Часть Stable ABI.
Асинхронно возбуждает исключение в потоке. Аргумент id – это идентификатор потока целевого потока; exc – это объект исключения, которое нужно возбудить. Эта функция не крадёт ссылки на exc. Для предотвращения наивного misuse требуется написать собственное C-расширение для её вызова. Должна вызываться с удержанием GIL. Возвращает количество изменённых состояний потока; обычно это единица, но будет нулём, если идентификатор потока не найден. Если exc равно
NULL, отложенное исключение (если есть) для потока очищается. Эта функция не возбуждает исключений.Изменено в версии 3.7: Тип параметра id изменён с long на unsigned long.
-
void PyEval_AcquireThread(PyThreadState *tstate)¶
- Часть Stable ABI.
Захватывает глобальную блокировку интерпретатора и устанавливает текущее состояние потока в tstate, которое не должно быть
NULL. Блокировка должна быть создана ранее. Если этот поток уже удерживает блокировку, возникает взаимоблокировка.Примечание
Вызов этой функции из потока, когда среда выполнения завершается, приведёт к зависанию потока до выхода из программы, даже если поток не был создан Python. Подробнее см. в Предостережения относительно завершения работы среды выполнения.
Изменено в версии 3.8: Функция обновлена для согласованности с
PyEval_RestoreThread(),Py_END_ALLOW_THREADS()иPyGILState_Ensure(), и теперь завершает текущий поток, если вызвана во время завершения работы интерпретатора.Изменено в версии 3.13.8: Вешает текущий поток, а не завершает его, если вызывается во время финализации интерпретатора.
PyEval_RestoreThread()– функция более высокого уровня, которая всегда доступна (даже если потоки не были инициализированы).
-
void PyEval_ReleaseThread(PyThreadState *tstate)¶
- Часть Stable ABI.
Сбрасывает текущее состояние потока в
NULLи освобождает глобальную блокировку интерпретатора. Блокировка должна быть создана ранее и должна удерживаться текущим потоком. Аргумент tstate, который не должен бытьNULL, используется только для проверки, что он представляет текущее состояние потока – если это не так, выводится фатальная ошибка.PyEval_SaveThread()– функция более высокого уровня, которая всегда доступна (даже если потоки не были инициализированы).
Поддержка под-интерпретаторов¶Sub-interpreter support
Хотя в большинстве случаев достаточно встроить один интерпретатор Python, бывают ситуации, когда требуется создать несколько независимых интерпретаторов в одном процессе и даже в одном потоке. Под-интерпретаторы позволяют это сделать.
«Главный» интерпретатор – это первый интерпретатор, создаваемый при инициализации среды выполнения.
Обычно он является единственным интерпретатором Python в процессе. В отличие от под-интерпретаторов, главный интерпретатор обладает уникальными общепроцессными обязанностями, такими как обработка сигналов. Он также отвечает за выполнение при инициализации среды выполнения и обычно является активным интерпретатором при завершении работы среды выполнения. Функция PyInterpreterState_Main() возвращает указатель на его состояние.
Переключаться между под-интерпретаторами можно с помощью функции PyThreadState_Swap().
Создавать и удалять их можно с помощью следующих функций:
-
type PyInterpreterConfig¶
Структура, содержащая большинство параметров для настройки под-интерпретатора. Её значения используются только в
Py_NewInterpreterFromConfig()и никогда не изменяются средой выполнения.Добавлено в версии 3.12.
Поля структуры:
-
int use_main_obmalloc¶
Если это
0, то под-интерпретатор будет использовать собственное состояние аллокатора «объектов». В противном случае он будет использовать (разделять) состояние главного интерпретатора.Если это
0, тоcheck_multi_interp_extensionsдолжен быть1(ненулевым). Если это1, тоgilне должен бытьPyInterpreterConfig_OWN_GIL.
-
int allow_fork¶
Если это
0, то среда выполнения не будет поддерживать создание форка процесса в любом потоке, где в данный момент активен под-интерпретатор. В противном случае форк не ограничен.Обратите внимание, что модуль
subprocessпо-прежнему работает, когда форк запрещён.
-
int allow_exec¶
Если это
0, то среда выполнения не будет поддерживать замену текущего процесса через exec (например,os.execv()) в любом потоке, где в данный момент активен под-интерпретатор. В противном случае exec не ограничен.Обратите внимание, что модуль
subprocessпо-прежнему работает, когда exec запрещён.
-
int allow_threads¶
Если это
0, то модульthreadingпод-интерпретатора не будет создавать потоки. В противном случае потоки разрешены.
-
int allow_daemon_threads¶
Если это
0, то модульthreadingпод-интерпретатора не будет создавать потоки-демоны. В противном случае потоки-демоны разрешены (при условии, чтоallow_threadsне равен нулю).
-
int check_multi_interp_extensions¶
Если это
0, то все модули расширений могут быть импортированы, включая устаревшие модули (с однофазной инициализацией), в любом потоке, где активен под-интерпретатор. В противном случае могут быть импортированы только модули расширений с многофазной инициализацией (см. PEP 489). (См. такжеPy_mod_multiple_interpreters.)Это должно быть
1(ненулевым), еслиuse_main_obmallocравно0.
-
int gil¶
Это определяет режим работы GIL для под-интерпретатора. Он может быть одним из следующих:
-
PyInterpreterConfig_DEFAULT_GIL¶
Использовать выбор по умолчанию (
PyInterpreterConfig_SHARED_GIL).
-
PyInterpreterConfig_SHARED_GIL¶
Использовать (разделять) GIL главного интерпретатора.
-
PyInterpreterConfig_OWN_GIL¶
Использовать собственный GIL под-интерпретатора.
Если это
PyInterpreterConfig_OWN_GIL, тоPyInterpreterConfig.use_main_obmallocдолжен быть0.-
PyInterpreterConfig_DEFAULT_GIL¶
-
int use_main_obmalloc¶
-
PyStatus Py_NewInterpreterFromConfig(PyThreadState **tstate_p, const PyInterpreterConfig *config)¶
Создаёт новый под-интерпретатор. Это (почти) полностью независимое окружение для выполнения кода Python. В частности, новый интерпретатор имеет отдельные, независимые версии всех импортированных модулей, включая фундаментальные модули
builtins,__main__иsys. Таблица загруженных модулей (sys.modules) и путь поиска модулей (sys.path) также отдельные. В новом окружении нет переменнойsys.argv. У него есть новые файловые объекты стандартных потоков ввода-выводаsys.stdin,sys.stdoutиsys.stderr(однако они ссылаются на те же нижележащие файловые дескрипторы).Переданный config управляет параметрами, с которыми инициализируется интерпретатор.
В случае успеха tstate_p будет установлен на первое состояние потока, созданное в новом под-интерпретаторе. Это состояние потока создаётся в текущем состоянии потока. Обратите внимание, что реальный поток не создаётся; см. обсуждение состояний потока ниже. Если создание нового интерпретатора не удаётся, tstate_p устанавливается в
NULL; исключение не устанавливается, так как состояние исключения хранится в текущем состоянии потока, и текущего состояния потока может не существовать.Как и все остальные функции Python/C API, перед вызовом этой функции должна быть захвачена глобальная блокировка интерпретатора, и она остаётся захваченной после возврата. Также при входе должно быть установлено текущее состояние потока. В случае успеха возвращённое состояние потока становится текущим. Если под-интерпретатор создаётся с собственным GIL, то GIL вызывающего интерпретатора будет освобождён. Когда функция возвращает управление, GIL нового интерпретатора будет захвачен текущим потоком, а GIL предыдущего интерпретатора останется освобождённым.
Добавлено в версии 3.12.
Под-интерпретаторы наиболее эффективны при изоляции друг от друга, с ограничением определённой функциональности:
PyInterpreterConfig config = { .use_main_obmalloc = 0, .allow_fork = 0, .allow_exec = 0, .allow_threads = 1, .allow_daemon_threads = 0, .check_multi_interp_extensions = 1, .gil = PyInterpreterConfig_OWN_GIL, }; PyThreadState *tstate = NULL; PyStatus status = Py_NewInterpreterFromConfig(&tstate, &config); if (PyStatus_Exception(status)) { Py_ExitStatusException(status); }
Обратите внимание, что config используется только кратковременно и не изменяется. Во время инициализации значения config преобразуются в различные значения
PyInterpreterState. Копия config только для чтения может быть сохранена внутри наPyInterpreterState.Модули расширения совместно используются (под-)интерпретаторами следующим образом:
Для модулей, использующих многофазную инициализацию, например
PyModule_FromDefAndSpec(), для каждого интерпретатора создаётся и инициализируется отдельный объект модуля. Между этими объектами модулей совместно используются только статические и глобальные переменные на уровне C.Для модулей, использующих однофазную инициализацию, например
PyModule_Create(), при первом импорте определённого расширения оно инициализируется обычным образом, и (поверхностная) копия его словаря модуля сохраняется. Когда то же расширение импортируется другим (под-)интерпретатором, новый модуль инициализируется и заполняется содержимым этой копии; функцияinitрасширения не вызывается. Таким образом, объекты в словаре модуля оказываются общими для (под-)интерпретаторов, что может вызывать нежелательное поведение (см. Ошибки и предостережения ниже).Обратите внимание, что это отличается от ситуации, когда расширение импортируется после полной повторной инициализации интерпретатора вызовом
Py_FinalizeEx()иPy_Initialize(); в этом случае функцияinitmoduleрасширения вызывается снова. Как и при многофазной инициализации, это означает, что между этими модулями совместно используются только статические и глобальные переменные на уровне C.
-
PyThreadState *Py_NewInterpreter(void)¶
- Часть Stable ABI.
Создаёт новый под-интерпретатор. По сути, это просто обёртка вокруг
Py_NewInterpreterFromConfig()с config, который сохраняет существующее поведение. Результатом является неизолированный под-интерпретатор, который разделяет GIL главного интерпретатора, допускает fork/exec, разрешает фоновые потоки и допускает модули с однофазной инициализацией.
-
void Py_EndInterpreter(PyThreadState *tstate)¶
- Часть Stable ABI.
Уничтожает (под-)интерпретатор, представленный указанным состоянием потока. Указанное состояние потока должно быть текущим состоянием потока. См. обсуждение состояний потока ниже. Когда вызов возвращает управление, текущее состояние потока равно
NULL. Все состояния потока, связанные с этим интерпретатором, уничтожаются. Глобальная блокировка интерпретатора, используемая целевым интерпретатором, должна быть захвачена перед вызовом этой функции. При возврате GIL не удерживается.Py_FinalizeEx()уничтожит все под-интерпретаторы, которые не были явно уничтожены к этому моменту.
Перинтерпретаторный GIL¶A Per-Interpreter GIL
С помощью Py_NewInterpreterFromConfig() можно создать
под-интерпретатор, который полностью изолирован от других интерпретаторов,
включая собственный GIL. Самое важное преимущество такой
изоляции в том, что такой интерпретатор может выполнять код Python без
блокировки другими интерпретаторами и не блокируя другие. Таким образом,
один процесс Python может по-настоящему использовать несколько ядер CPU
при выполнении кода Python. Изоляция также поощряет иной подход к параллелизму,
отличный от простого использования потоков.
(См. PEP 554 и PEP 684.)
Использование изолированного интерпретатора требует бдительности для сохранения этой
изоляции. Это особенно означает, что нельзя совместно использовать объекты или изменяемое
состояние без гарантий потокобезопасности. Даже объекты, которые в остальном
неизменяемы (например, None, (1, 5)), обычно не могут быть использованы совместно
из-за счётчика ссылок. Один простой, но менее эффективный подход
– использовать глобальную блокировку при любом использовании некоторого состояния (или объекта).
С другой стороны, эффективно неизменяемые объекты (такие как целые числа или строки)
можно сделать безопасными, несмотря на их счётчики ссылок, сделав их бессмертными.
Фактически, это уже сделано для встроенных синглтонов, маленьких целых чисел
и ряда других встроенных объектов.
Если сохранять изоляцию, то будет доступ к настоящим многоядерным вычислениям без осложнений, связанных со свободной многопоточностью. Несоблюдение изоляции приведёт ко всем последствиям свободной многопоточности, включая гонки и трудноотлаживаемые крахи.
Кроме того, одна из главных проблем использования нескольких изолированных интерпретаторов – как безопасно (не нарушая изоляцию) и эффективно общаться между ними. Среда выполнения и стандартная библиотека пока не предоставляют стандартного подхода для этого. Будущий модуль стандартной библиотеки поможет уменьшить усилия по сохранению изоляции и предоставит эффективные инструменты для обмена (и совместного использования) данными между интерпретаторами.
Добавлено в версии 3.12.
Ошибки и предостережения¶Bugs and caveats
Поскольку под-интерпретаторы (и главный интерпретатор) являются частью одного
процесса, изоляция между ними не идеальна – например, с помощью
низкоуровневых файловых операций, таких как os.close(), они могут
(случайно или намеренно) влиять на открытые файлы друг друга. Из-за
того, как расширения совместно используются (под-)интерпретаторами, некоторые расширения могут
работать некорректно; это особенно вероятно при использовании однофазной инициализации
или (статических) глобальных переменных.
Можно вставлять объекты, созданные в одном под-интерпретаторе, в
пространство имён другого (под-)интерпретатора; этого следует избегать, если возможно.
Следует проявлять особую осторожность, чтобы избежать совместного использования пользовательских функций, методов, экземпляров или классов между под-интерпретаторами, поскольку операции импорта, выполняемые такими объектами, могут повлиять на словарь загруженных модулей не того (под-)интерпретатора. Не менее важно избегать совместного использования объектов, из которых доступны вышеперечисленные.
Также обратите внимание, что комбинирование этой функциональности с API PyGILState_*
является деликатным, поскольку эти API предполагают взаимно однозначное соответствие между состояниями потоков Python
и потоками уровня ОС, а это предположение нарушается наличием под-интерпретаторов.
Настоятельно рекомендуется не переключать под-интерпретаторы между парой
соответствующих вызовов PyGILState_Ensure() и PyGILState_Release().
Более того, расширения (такие как ctypes), использующие эти API для вызова
кода Python из потоков, созданных не в Python, вероятно, будут работать неправильно при использовании
под-интерпретаторов.
Асинхронные уведомления¶Asynchronous Notifications
Предоставляется механизм для асинхронных уведомлений основному потоку интерпретатора. Эти уведомления имеют форму указателя на функцию и аргумента в виде указателя void.
-
int Py_AddPendingCall(int (*func)(void*), void *arg)¶
- Часть Stable ABI.
Планирует вызов функции из основного потока интерпретатора. В случае успеха возвращается
0, и func помещается в очередь для вызова в основном потоке. В случае неудачи возвращается-1без установки какого-либо исключения.При успешной постановке в очередь func будет в конечном итоге вызвана из основного потока интерпретатора с аргументом arg. Она будет вызвана асинхронно по отношению к нормально выполняющемуся коду Python, но при соблюдении обоих этих условий:
на границе байткода;
при этом главный поток удерживает глобальную блокировку интерпретатора (поэтому func может использовать полный C API).
func должна возвращать
0при успехе или-1при неудаче с установленным исключением. func не будет прервана для рекурсивного выполнения другого асинхронного уведомления, но её всё ещё можно прервать для переключения потоков, если глобальная блокировка интерпретатора освобождена.Для выполнения этой функции не требуется текущее состояние потока, и ей не нужна глобальная блокировка интерпретатора.
Для вызова этой функции в под-интерпретаторе вызывающий должен удерживать GIL. В противном случае функция func может быть запланирована к вызову из неправильного интерпретатора.
Предупреждение
Это низкоуровневая функция, полезная только в особых случаях. Нет гарантии, что func будет вызвана максимально быстро. Если главный поток занят выполнением системного вызова, func не будет вызвана до возврата из системного вызова. Эта функция в целом не подходит для вызова кода Python из произвольных C-потоков. Вместо неё используйте PyGILState API.
Добавлено в версии 3.1.
Изменено в версии 3.9: Если эта функция вызывается в подынтерпретаторе, функция func теперь планируется для вызова из подынтерпретатора, а не из основного интерпретатора. Каждый подынтерпретатор теперь имеет свой собственный список запланированных вызовов.
Изменено в версии 3.12: Эта функция теперь всегда планирует выполнение func в основном интерпретаторе.
-
int Py_MakePendingCalls(void)¶
- Часть Stable ABI.
Выполняет все отложенные вызовы. Обычно это выполняется автоматически интерпретатором.
Эта функция возвращает
0при успехе и-1с установленным исключением при ошибке.Если эта функция вызывается не в главном потоке главного интерпретатора, она ничего не делает и возвращает
0. Вызывающий должен удерживать GIL.Добавлено в версии 3.1.
Изменено в версии 3.12: Эта функция выполняет отложенные вызовы только в основном интерпретаторе.
Профилирование и трассировка¶Profiling and Tracing
Интерпретатор Python предоставляет низкоуровневую поддержку для подключения средств профилирования и трассировки выполнения. Они используются в инструментах профилирования, отладки и анализа покрытия.
Этот C-интерфейс позволяет коду профилирования или трассировки избежать накладных расходов на вызов через вызываемые объекты уровня Python, выполняя вместо этого прямой вызов C-функции. Основные характеристики механизма не изменились; интерфейс позволяет устанавливать функции трассировки для каждого потока, а базовые события, сообщаемые функции трассировки, такие же, как и в предыдущих версиях для функций трассировки уровня Python.
-
typedef int (*Py_tracefunc)(PyObject *obj, PyFrameObject *frame, int what, PyObject *arg)¶
Тип функции трассировки, регистрируемой с помощью
PyEval_SetProfile()иPyEval_SetTrace(). Первый параметр – это объект, переданный функции регистрации как obj, frame – это объект фрейма, к которому относится событие, what – одна из константPyTrace_CALL,PyTrace_EXCEPTION,PyTrace_LINE,PyTrace_RETURN,PyTrace_C_CALL,PyTrace_C_EXCEPTION,PyTrace_C_RETURNилиPyTrace_OPCODE, а arg зависит от значения what:Значение what
Смысл arg
Всегда
Py_None.Информация об исключении, возвращаемая
sys.exc_info().Всегда
Py_None.Значение, возвращаемое вызывающему коду, или
NULL, если вызвано исключением.Вызываемый объект функции.
Вызываемый объект функции.
Вызываемый объект функции.
Всегда
Py_None.
-
int PyTrace_CALL¶
Значение параметра what для функции
Py_tracefunc, когда сообщается о новом вызове функции или метода, или о новом входе в генератор. Обратите внимание, что создание итератора для функции-генератора не сообщается, поскольку в соответствующем фрейме не происходит передачи управления байт-коду Python.
-
int PyTrace_EXCEPTION¶
Значение параметра what для функции
Py_tracefunc, когда возникло исключение. Функция обратного вызова вызывается с этим значением для what после обработки любого байт-кода, после которого исключение становится установленным в выполняемом фрейме. В результате, когда распространение исключения вызывает раскрутку стека Python, функция обратного вызова вызывается при возврате в каждый фрейм по мере распространения исключения. Только функции трассировки получают эти события; профилировщику они не нужны.
-
int PyTrace_LINE¶
Значение, передаваемое в качестве параметра what функции
Py_tracefunc(но не функции профилирования), когда сообщается о событии номера строки. Его можно отключить для фрейма, установивf_trace_linesв 0 в этом фрейме.
-
int PyTrace_RETURN¶
Значение параметра what для функций
Py_tracefunc, когда вызов собирается вернуться.
-
int PyTrace_C_CALL¶
Значение параметра what для функций
Py_tracefunc, когда собирается быть вызвана C-функция.
-
int PyTrace_C_EXCEPTION¶
Значение параметра what для функций
Py_tracefunc, когда C-функция вызвала исключение.
-
int PyTrace_C_RETURN¶
Значение параметра what для функций
Py_tracefunc, когда C-функция вернулась.
-
int PyTrace_OPCODE¶
Значение параметра what для функций
Py_tracefunc(но не функций профилирования), когда собирается быть выполнен новый опкод. Это событие не генерируется по умолчанию: его нужно явно запросить, установивf_trace_opcodesв 1 во фрейме.
-
void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)¶
Устанавливает функцию профилирования в func. Параметр obj передаётся функции в качестве первого аргумента; это может быть любой объект Python или
NULL. Если функции профилирования нужно поддерживать состояние, использование разных значений obj для каждого потока предоставляет удобное и потокобезопасное место для его хранения. Функция профилирования вызывается для всех отслеживаемых событий, кромеPyTrace_LINE,PyTrace_OPCODEиPyTrace_EXCEPTION.См. также функцию
sys.setprofile().Вызывающий должен удерживать GIL.
-
void PyEval_SetProfileAllThreads(Py_tracefunc func, PyObject *obj)¶
Как
PyEval_SetProfile(), но устанавливает функцию профилирования во всех работающих потоках, принадлежащих текущему интерпретатору, а не только в текущем потоке.Вызывающий должен удерживать GIL.
Как и
PyEval_SetProfile(), эта функция игнорирует любые исключения, возникшие при установке функций профилирования во всех потоках.
Добавлено в версии 3.12.
-
void PyEval_SetTrace(Py_tracefunc func, PyObject *obj)¶
Устанавливает функцию трассировки в func. Это похоже на
PyEval_SetProfile(), за исключением того, что функция трассировки получает события номеров строк и события на каждую операцию, но не получает событий, связанных с вызовом объектов функций C. Любая функция трассировки, зарегистрированная черезPyEval_SetTrace(), не будет получатьPyTrace_C_CALL,PyTrace_C_EXCEPTIONилиPyTrace_C_RETURNв качестве значения параметра what.См. также функцию
sys.settrace().Вызывающий должен удерживать GIL.
-
void PyEval_SetTraceAllThreads(Py_tracefunc func, PyObject *obj)¶
Как
PyEval_SetTrace(), но устанавливает функцию трассировки во всех работающих потоках, принадлежащих текущему интерпретатору, а не только в текущем потоке.Вызывающий должен удерживать GIL.
Как и
PyEval_SetTrace(), эта функция игнорирует любые исключения, возникшие при установке функций трассировки во всех потоках.
Добавлено в версии 3.12.
Трассировка ссылок¶Reference tracing
Добавлено в версии 3.13.
-
typedef int (*PyRefTracer)(PyObject*, int event, void *data)¶
Тип функции трассировки, регистрируемой с помощью
PyRefTracer_SetTracer(). Первый параметр – это объект Python, который только что был создан (когда event установлен вPyRefTracer_CREATE) или собирается быть уничтожен (когда event установлен вPyRefTracer_DESTROY). Аргумент data – это непрозрачный указатель, который был предоставлен при вызовеPyRefTracer_SetTracer().
Добавлено в версии 3.13.
-
int PyRefTracer_CREATE¶
Значение параметра event для функций
PyRefTracer, когда объект Python был создан.
-
int PyRefTracer_DESTROY¶
Значение параметра event для функций
PyRefTracer, когда объект Python был уничтожен.
-
int PyRefTracer_SetTracer(PyRefTracer tracer, void *data)¶
Регистрирует функцию-трассировщик ссылок. Эта функция будет вызываться при создании нового объекта Python или при уничтожении объекта. Если data передан, он должен быть непрозрачным указателем, который будет передаваться при вызове трассировщика. Возвращает
0при успехе. Устанавливает исключение и возвращает-1при ошибке.Обратите внимание, что функции-трассировщики не должны создавать объекты Python внутри, иначе вызов станет реентерабельным. Трассировщик также не должен очищать существующее исключение или устанавливать исключение. GIL будет удерживаться каждый раз при вызове функции-трассировщика.
При вызове этой функции необходимо удерживать GIL.
Добавлено в версии 3.13.
-
PyRefTracer PyRefTracer_GetTracer(void **data)¶
Возвращает зарегистрированную функцию трассировки ссылок и значение непрозрачного указателя данных, который был зарегистрирован при вызове
PyRefTracer_SetTracer(). Если трассировщик не был зарегистрирован, эта функция вернёт NULL и установит указатель data в NULL.При вызове этой функции необходимо удерживать GIL.
Добавлено в версии 3.13.
Поддержка расширенного отладчика¶Advanced Debugger Support
Эти функции предназначены только для использования расширенными инструментами отладки.
-
PyInterpreterState *PyInterpreterState_Head()¶
Возвращает объект состояния интерпретатора, находящийся в начале списка всех таких объектов.
-
PyInterpreterState *PyInterpreterState_Main()¶
Возвращает объект состояния основного интерпретатора.
-
PyInterpreterState *PyInterpreterState_Next(PyInterpreterState *interp)¶
Возвращает следующий объект состояния интерпретатора после interp из списка всех таких объектов.
-
PyThreadState *PyInterpreterState_ThreadHead(PyInterpreterState *interp)¶
Возвращает указатель на первый объект
PyThreadStateв списке потоков, связанных с интерпретатором interp.
-
PyThreadState *PyThreadState_Next(PyThreadState *tstate)¶
Возвращает следующий объект состояния потока после tstate из списка всех таких объектов, принадлежащих тому же объекту
PyInterpreterState.
Поддержка локального хранилища потоков¶Thread Local Storage Support
Интерпретатор Python предоставляет низкоуровневую поддержку для потоково-локального хранилища
(TLS), которая оборачивает базовую нативную реализацию TLS для поддержки
API потоково-локального хранилища на уровне Python (threading.local).
API CPython на уровне C похожи на те, что предоставляются pthreads и Windows:
используется ключ потока и функции для ассоциации void* значения на
поток.
GIL не нужно удерживать при вызове этих функций; они обеспечивают собственную блокировку.
Обратите внимание, что Python.h не содержит объявления TLS-функций; для использования локальной памяти потока необходимо включить pythread.h.
Примечание
Ни одна из этих функций API не занимается управлением памятью для значений void*. Вы должны сами выделять и освобождать память. Если значения void* оказываются PyObject*, эти функции также не выполняют операции с подсчётом ссылок.
API потоково-специфичного хранилища (TSS)¶Thread Specific Storage (TSS) API
API TSS введен для замены использования существующего API TLS в
интерпретаторе CPython. Этот API использует новый тип Py_tss_t вместо
int для представления ключей потоков.
Добавлено в версии 3.7.
См. также
«Новый C-API для локальной памяти потока в CPython» (PEP 539)
-
type Py_tss_t¶
Эта структура данных представляет состояние ключа потока; её определение может зависеть от конкретной реализации TLS, и она содержит внутреннее поле, отражающее состояние инициализации ключа. Открытых членов этой структуры нет.
Если Py_LIMITED_API не определён, допускается статическое размещение этого типа с помощью
Py_tss_NEEDS_INIT.
-
Py_tss_NEEDS_INIT¶
Этот макрос раскрывается в инициализатор для переменных типа
Py_tss_t. Обратите внимание, что этот макрос не будет определён вместе с Py_LIMITED_API.
Динамическое выделение¶Dynamic Allocation
Динамическое выделение Py_tss_t требуется в модулях расширения, собранных с Py_LIMITED_API, где статическое размещение этого типа невозможно из-за того, что его реализация скрыта во время сборки.
-
Py_tss_t *PyThread_tss_alloc()¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает значение, находящееся в том же состоянии, что и значение, инициализированное с помощью
Py_tss_NEEDS_INIT, илиNULLв случае ошибки динамического выделения.
-
void PyThread_tss_free(Py_tss_t *key)¶
- Часть Stable ABI начиная с версии 3.7.
Освобождает заданный key, выделенный с помощью
PyThread_tss_alloc(), предварительно вызвавPyThread_tss_delete(), чтобы сбросить все привязанные к нему локальные данные потока. Эта операция ничего не делает, если аргумент key равенNULL.Примечание
Освобождённый ключ становится висячим указателем. Следует сбросить ключ обратно в
NULL.
Методы¶Methods
Параметр key этих функций не должен быть NULL. Кроме того, поведение PyThread_tss_set() и PyThread_tss_get() не определено, если заданный Py_tss_t не был инициализирован с помощью PyThread_tss_create().
-
int PyThread_tss_is_created(Py_tss_t *key)¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает ненулевое значение, если заданный
Py_tss_tбыл инициализирован с помощьюPyThread_tss_create().
-
int PyThread_tss_create(Py_tss_t *key)¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает нулевое значение при успешной инициализации TSS-ключа. Поведение не определено, если значение, на которое указывает аргумент key, не инициализировано с помощью
Py_tss_NEEDS_INIT. Эту функцию можно вызывать для одного и того же ключа многократно – вызов для уже инициализированного ключа ничего не делает и сразу возвращает успех.
-
void PyThread_tss_delete(Py_tss_t *key)¶
- Часть Stable ABI начиная с версии 3.7.
Уничтожает TSS-ключ, забывая связанные с ним значения во всех потоках, и переводит состояние инициализации ключа в «не инициализирован». Уничтоженный ключ можно повторно инициализировать с помощью
PyThread_tss_create(). Эту функцию можно вызывать для одного и того же ключа многократно – вызов для уже уничтоженного ключа ничего не делает.
-
int PyThread_tss_set(Py_tss_t *key, void *value)¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает нулевое значение при успешной привязке значения void* к TSS-ключу в текущем потоке. Каждый поток имеет собственное отображение ключа на значение void*.
-
void *PyThread_tss_get(Py_tss_t *key)¶
- Часть Stable ABI начиная с версии 3.7.
Возвращает значение void*, связанное с ключом TSS в текущем потоке. Возвращает
NULL, если с ключом в текущем потоке не связано никакого значения.
API локального хранилища потоков (TLS)¶Thread Local Storage (TLS) API
Устарело с версии 3.7: Этот API заменён API поток-специфичного хранилища (TSS).
Примечание
Эта версия API не поддерживает платформы, где нативный ключ TLS
определён так, что его нельзя безопасно привести к int. На таких платформах
PyThread_create_key() немедленно возвращает статус ошибки,
а остальные функции TLS на таких платформах ничего не делают.
Из-за упомянутой выше проблемы совместимости эту версию API не следует использовать в новом коде.
-
int PyThread_create_key()¶
- Часть Stable ABI.
-
void PyThread_delete_key(int key)¶
- Часть Stable ABI.
-
int PyThread_set_key_value(int key, void *value)¶
- Часть Stable ABI.
-
void *PyThread_get_key_value(int key)¶
- Часть Stable ABI.
-
void PyThread_delete_key_value(int key)¶
- Часть Stable ABI.
-
void PyThread_ReInitTLS()¶
- Часть Stable ABI.
Примитивы синхронизации¶Synchronization Primitives
C-API предоставляет базовую блокировку взаимного исключения.
-
type PyMutex¶
Блокировка взаимного исключения.
PyMutexследует инициализировать нулём для представления разблокированного состояния. Например:PyMutex mutex = {0};
Экземпляры
PyMutexне должны копироваться или перемещаться. Как содержимое, так и адресPyMutexимеют смысл, и он должен оставаться в фиксированном, доступном для записи месте в памяти.Примечание
PyMutexв настоящее время занимает один байт, но размер следует считать нестабильным. Размер может измениться в будущих выпусках Python без периода устаревания.Добавлено в версии 3.13.
-
void PyMutex_Lock(PyMutex *m)¶
Блокирует мьютекс m. Если другой поток уже заблокировал его, вызывающий поток будет ожидать, пока мьютекс не будет разблокирован. Во время ожидания поток временно освободит GIL, если он удерживается.
Добавлено в версии 3.13.
-
void PyMutex_Unlock(PyMutex *m)¶
Разблокирует мьютекс m. Мьютекс должен быть заблокирован – в противном случае функция выдаст фатальную ошибку.
Добавлено в версии 3.13.
API критических секций Python¶Python Critical Section API
API критических секций предоставляет уровень предотвращения взаимных блокировок поверх объектных блокировок для свободно-поточного CPython. Они предназначены для замены зависимости от глобальной блокировки интерпретатора и являются пустышками (no-op) в версиях Python с глобальной блокировкой интерпретатора.
Критические секции предназначены для использования с пользовательскими типами, реализованными в расширениях C-API. Их обычно не следует использовать со встроенными типами, такими как list и dict, поскольку их публичные C-API уже внутренне используют критические секции, за заметным исключением PyDict_Next(), для которого требуется внешнее получение критической секции.
Критические секции предотвращают взаимные блокировки, неявно приостанавливая активные критические секции, поэтому они не предоставляют исключительный доступ, как традиционные блокировки, например PyMutex. При запуске критической секции захватывается объектная блокировка для данного объекта. Если код, выполняемый внутри критической секции, вызывает функции C-API, то он может приостановить критическую секцию, тем самым освободив объектную блокировку, так что другие потоки смогут захватить объектную блокировку для того же объекта.
Функции и структуры, используемые макросами, предоставлены для случаев, когда макросы C недоступны. Их следует использовать только так, как в соответствующих развёртках макросов. Учтите, что размеры и содержимое структур могут измениться в будущих версиях Python.
Примечание
Операции, которым необходимо заблокировать два объекта одновременно, должны использовать Py_BEGIN_CRITICAL_SECTION2. Нельзя использовать вложенные критические секции для блокировки более одного объекта одновременно, поскольку внутренняя критическая секция может приостановить внешние критические секции. Этот API не предоставляет способа заблокировать более двух объектов одновременно.
Пример использования:
static PyObject *
set_field(MyObject *self, PyObject *value)
{
Py_BEGIN_CRITICAL_SECTION(self);
Py_SETREF(self->field, Py_XNewRef(value));
Py_END_CRITICAL_SECTION();
Py_RETURN_NONE;
}
В приведённом выше примере Py_SETREF вызывает Py_DECREF, который может вызывать произвольный код через функцию освобождения объекта. API критических секций избегает потенциальных взаимных блокировок из-за повторного входа и порядка блокировок, позволяя среде выполнения временно приостанавливать критическую секцию, если код, запущенный финализатором, блокируется и вызывает PyEval_SaveThread().
-
Py_BEGIN_CRITICAL_SECTION(op)¶
Захватывает объектную блокировку для объекта op и начинает критическую секцию.
В сборке free-threaded этот макрос раскрывается в:
{ PyCriticalSection _py_cs; PyCriticalSection_Begin(&_py_cs, (PyObject*)(op))
В сборке по умолчанию этот макрос раскрывается в
{.Добавлено в версии 3.13.
-
Py_END_CRITICAL_SECTION()¶
Завершает критическую секцию и освобождает блокировку объекта.
В сборке free-threaded этот макрос раскрывается в:
PyCriticalSection_End(&_py_cs); }
В сборке по умолчанию этот макрос раскрывается в
}.Добавлено в версии 3.13.
-
Py_BEGIN_CRITICAL_SECTION2(a, b)¶
Захватывает блокировки для объектов a и b и начинает критическую секцию. Блокировки захватываются в согласованном порядке (сначала наименьший адрес), чтобы избежать взаимоблокировок из-за порядка блокировок.
В сборке free-threaded этот макрос раскрывается в:
{ PyCriticalSection2 _py_cs2; PyCriticalSection2_Begin(&_py_cs2, (PyObject*)(a), (PyObject*)(b))
В сборке по умолчанию этот макрос раскрывается в
{.Добавлено в версии 3.13.
-
Py_END_CRITICAL_SECTION2()¶
Завершает критическую секцию и освобождает блокировки объектов.
В сборке free-threaded этот макрос раскрывается в:
PyCriticalSection2_End(&_py_cs2); }
В сборке по умолчанию этот макрос раскрывается в
}.Добавлено в версии 3.13.
Устаревшие API блокировок¶Legacy Locking APIs
Эти API устарели с Python 3.13 с введением PyMutex.
Изменено в версии 3.15: Теперь эти API представляют собой простую обёртку вокруг PyMutex.
-
type PyThread_type_lock¶
Указатель на блокировку взаимного исключения.
-
type PyLockStatus¶
Результат захвата блокировки с таймаутом.
-
enumerator PY_LOCK_FAILURE¶
Не удалось захватить блокировку.
-
enumerator PY_LOCK_ACQUIRED¶
Блокировка успешно захвачена.
-
enumerator PY_LOCK_INTR¶
Захват блокировки прерван сигналом.
-
enumerator PY_LOCK_FAILURE¶
-
PyThread_type_lock PyThread_allocate_lock(void)¶
- Часть Stable ABI.
Выделить новую блокировку.
В случае успеха функция возвращает блокировку; в случае неудачи возвращает
0без установленного исключения.Вызывающему не нужно удерживать GIL.
Изменено в версии 3.15: Теперь эта функция всегда использует
PyMutex. В предыдущих версиях использовалась блокировка, предоставляемая операционной системой.
-
void PyThread_free_lock(PyThread_type_lock lock)¶
- Часть Stable ABI.
Уничтожить блокировку. Блокировка не должна удерживаться ни одним потоком при вызове этой функции.
Вызывающему не нужно удерживать GIL.
-
PyLockStatus PyThread_acquire_lock_timed(PyThread_type_lock lock, long long microseconds, int intr_flag)¶
- Часть Stable ABI.
Захватить блокировку с таймаутом.
Будет ожидать microseconds микросекунд для захвата блокировки. Если таймаут истекает, функция возвращает
PY_LOCK_FAILURE. Если microseconds равно-1, будет ожидать неопределённо долго, пока блокировка не будет освобождена.Если intr_flag равно
1, захват блокировки может быть прерван сигналом, и в этом случае функция возвращаетPY_LOCK_INTR. После прерывания ожидается, что вызывающая сторона вызоветPy_MakePendingCalls()для передачи исключения в код Python.Если блокировка успешно захвачена, функция возвращает
PY_LOCK_ACQUIRED.Вызывающему не нужно удерживать GIL.
-
int PyThread_acquire_lock(PyThread_type_lock lock, int waitflag)¶
- Часть Stable ABI.
Захватить блокировку.
Если waitflag равно
1, и другой поток в данный момент удерживает блокировку, эта функция будет ждать, пока блокировка не будет захвачена, и всегда будет возвращать1.Если waitflag равно
0, и другой поток удерживает блокировку, эта функция не будет ждать, а вернёт0. Если блокировка не удерживается никаким другим потоком, то эта функция захватит её и вернёт1.В отличие от
PyThread_acquire_lock_timed(), захват блокировки не может быть прерван сигналом.Вызывающему не нужно удерживать GIL.
-
int PyThread_release_lock(PyThread_type_lock lock)¶
- Часть Stable ABI.
Освободить блокировку. Если блокировка не удерживается, то эта функция вызовет фатальную ошибку.
Вызывающему не нужно удерживать GIL.
API потоков операционной системы¶Operating System Thread APIs
-
PYTHREAD_INVALID_THREAD_ID¶
Страж-значение для недопустимого идентификатора потока.
В настоящее время эквивалентно
(unsigned long)-1.
-
unsigned long PyThread_start_new_thread(void (*func)(void*), void *arg)¶
- Часть Stable ABI.
Запускает функцию func в новом потоке с аргументом arg. Полученный поток не предназначен для ожидания завершения.
func не должна быть
NULL, но arg может бытьNULL.При успехе эта функция возвращает идентификатор нового потока; при неудаче возвращает
PYTHREAD_INVALID_THREAD_ID.Вызывающему не нужно удерживать GIL.
-
unsigned long PyThread_get_thread_ident(void)¶
- Часть Stable ABI.
Возвращает идентификатор текущего потока, который никогда не будет равен нулю.
Эта функция не может завершиться ошибкой, и вызывающему не нужно удерживать GIL.
См. также
-
PyObject *PyThread_GetInfo(void)¶
- Часть Stable ABI начиная с версии 3.3.
Получает общую информацию о текущем потоке в виде объекта структурной последовательности. Эта информация доступна как
sys.thread_infoв Python.В случае успеха возвращается новая сильная ссылка на информацию о потоке; в случае неудачи возвращается
NULLс установленным исключением.Вызывающий должен удерживать GIL.
-
PY_HAVE_THREAD_NATIVE_ID¶
Этот макрос определён, когда система поддерживает нативные идентификаторы потоков.
-
unsigned long PyThread_get_thread_native_id(void)¶
- Часть Stable ABI на платформах с нативными идентификаторами потоков.
Возвращает нативный идентификатор текущего потока, назначенный ядром операционной системы; это значение никогда не бывает меньше нуля.
Эта функция доступна, только если определён
PY_HAVE_THREAD_NATIVE_ID.Эта функция не может завершиться ошибкой, и вызывающему не нужно удерживать GIL.
См. также
-
void PyThread_exit_thread(void)¶
- Часть Stable ABI.
Завершает текущий поток. Эта функция обычно считается небезопасной, и её следует избегать. Она сохранена исключительно для обратной совместимости.
Эту функцию безопасно вызывать, только если все функции в полном стеке вызовов написаны так, чтобы допускать это безопасно.
Предупреждение
Если текущая система использует потоки POSIX (также известные как «pthreads»), эта функция вызывает pthread_exit(3), которая пытается развернуть стек и вызвать деструкторы C++ в некоторых реализациях libc. Однако, если достигается функция
noexcept, это может завершить процесс. Другие системы, такие как macOS, выполняют развёртывание.В Windows эта функция вызывает
_endthreadex(), которая уничтожает поток без вызова деструкторов C++.В любом случае существует риск повреждения стека потока.
-
void PyThread_init_thread(void)¶
- Часть Stable ABI.
Инициализирует API
PyThread*. Python выполняет эту функцию автоматически, поэтому нет особой необходимости вызывать её из расширяющего модуля.
-
int PyThread_set_stacksize(size_t size)¶
- Часть Stable ABI.
Устанавливает размер стека текущего потока в size байт.
Эта функция возвращает
0при успехе,-1, если size некорректен, или-2, если система не поддерживает изменение размера стека. Эта функция не устанавливает исключения.Вызывающему не нужно удерживать GIL.
-
size_t PyThread_get_stacksize(void)¶
- Часть Stable ABI.
Возвращает размер стека текущего потока в байтах или
0, если используется размер стека по умолчанию для системы.Вызывающему не нужно удерживать GIL.