Действительно ли Python GIL рассчитан на интерпретатор?

Я часто вижу, как люди говорят, что GIL предназначен для интерпретатора Python (даже здесь, в stackoverflow).

Но то, что я вижу в исходном коде, похоже, что GIL - это глобальная переменная, и поэтому существует один GIL для всех интерпретаторов в каждом процессе Python. Я знаю, что они сделали это, потому что здесь нет объекта-интерпретатора, который передается, как lua ​​или TCL, просто он изначально был плохо спроектирован. И локальное хранилище потоков кажется непереносимым для использования разработчиками Python.

Это правильно? Я кратко ознакомился с версией 2.4, которую использую в этом проекте.

Изменилось ли это в более поздних версиях, особенно в 3.0?


python multithreading gil
person Lothar    schedule 18.10.2009    source источник

Ответы (3)


arrow_upward
10
arrow_downward

GIL действительно предназначен для каждого процесса, а не для каждого интерпретатора. Это не изменилось в 3.x.

person Martin v. Löwis    schedule 18.10.2009

arrow_upward
3
arrow_downward

Возможно, путаница возникает из-за того, что большинство людей считает, что у Python есть один интерпретатор для каждого процесса. Я помню, как читал, что поддержка нескольких интерпретаторов через C API в основном не тестировалась и почти никогда не использовалась. (И когда я попробовал, не сработало должным образом.)

person Kylotan    schedule 18.10.2009

arrow_upward
0
arrow_downward

Я считаю, что это правда (по крайней мере, с Python 2.6), что каждый процесс может иметь не более одного встроенного интерпретатора CPython (другие среды выполнения могут иметь другие ограничения). Я не уверен, что это проблема GIL как такового, но, вероятно, это связано с глобальным состоянием или для защиты от конфликтующего глобального состояния в сторонних модулях C. Из документации CPython API:

[Py ___ Initialize ()] не работает при повторном вызове (без первого вызова Py_Finalize ()). Нет возвращаемого значения; если инициализация не удалась, это фатальная ошибка.

Возможно, вас заинтересует проект Unladen Swallow, который в конечном итоге направлен на удаление GIL полностью из CPython. В других средах выполнения Python вообще нет GIL, например (я считаю) Stackless Python и, конечно, Jython.

Также обратите внимание, что GIL - это все еще присутствует в CPython 3.x.

person dcrosta    schedule 18.10.2009
comment
Раньше многие проекты удаляли GIL из CPython. Unladen Swallow - не первая. Однако они не работали так хорошо, как версия GIL, поэтому их никто не использует. - person nosklo; 19.10.2009
comment
Кроме того, без стека не удаляется GIL. Фактически, любая операция блокировки в любом микропотоке без стека будет блокировать все приложение. - person nosklo; 19.10.2009
comment
И Jython настолько медленный, что его тоже нельзя использовать - если только вы не используете его только для плагина сценариев к java-программе, где большая часть работы выполняется на Python. - person Lothar; 08.07.2012