Написал две статьи: http://asvetlov.blogspot.com/2011/07/gil.html и http://asvetlov.blogspot.com/2011/07/signal.html

Комментарии и критика — приветствуются.

Очень подробно расписано.
Но зачем он нужен? Что было-бы если работать без gil, например если запустить 2 потока с математической нагрузкой?

В 3.2 потоки ОСи дают маленький плюс, но для 2.х было бы выгодней что-б питон был однопоточный, все равно переключение между питоновскими потоками происходит в одном и том же месте, а ресурсы (процессора) на “висячие” потоки ОСи тратятся. так?

Ещё вопрос появился, можно как-нибудь получиться статистику о конкуренции потоков за gil? Что-б можно было-б вычислить оптимальное кол-во потоков на wsgi.

Без GIL многопоточное приложение сломалось бы на удалении объектов.
Про траты на “висячие” потоки — не совсем оно так. Тут случай запутанный, висеть можно по разному. Если поток уперся в лок, то на него невозможно переключиться. Но в целом для тройки получился менее прожорливый механизм.

Нужная вам статистика — это банальная загрузка процессора. Доведите её до максимальной, вот и все дела.

Андрей Светлов
Без GIL многопоточное приложение сломалось бы на удалении объектов.

На удалении общих объектов? А если общие объекты удалять при завершении последнего потока?

Питон не может знать, общий объект или нет. Поэтому удаляет всех одинаково.

Почему у других языков получается удалять объекты без GIL и только у питона с этим какие-то проблемы?

Изучаю конкретно питон всего пару недель, но считаю что в эру многоядерных систем использование GIL критически неудачное решение. Во всём другом питон очень даже нравится

xneo
Питон зарождался не в эту эпоху. В эту эпоху есть PyPy - неофициальная версия Python без GIL

xneo
эру многоядерных систем использование GIL критически неудачное решение

На самом деле не настолько важно. Python вообще не очень производительный. Критические к времени части все равно пишутся на C. И если вам надо вы можете загрузить ядра на более нижнем уровне. Точнее вы сначала перепишете критические части на C (получите прирост 3-100 раз). А потом будете использовать треды.

Комментарии по статям.
Мы уже обсуждали, но следует наверное отметить, что для windows, у которого как отмечено свои тараканы, порождение процесса крайне дорогая операция, что сильно ограничивает применение multiprocessing. Не стоит забывать что при этом используется другой механизм разделения данных, который кардинально меняет архитектуру приложения. Так что трудно согласится что этот подход лучше чем использование C-API.

Складывается впечатление что threding в питоне вообще не нужен, и причина его сохранения чисто обратная совместимость (если надо треды я отлично и из C запущу). Его могут заменить поддержка coroutines и механизмы передачи сообщений. Что-то типа mpi, zeromq или pyro4 например. Вы согласитесь с таким взглядом на проблему?

> Складывается впечатление что threding в питоне вообще не нужен
Потоки нужны, но не для распараллеливания. ИХМО из-за GIL их можно рассматривать как своеобразную реализацию асинхронности.