Публикации с меткой «threads»

Предыстория

На хабре неоднократно упоминались различные инструменты и способы создания скриншотов WEB страниц.

Хочу поделиться собственным «велосипедом» для создания PDF на Python и QT, дополненным и улучшенным для централизованного использования несколькими проектами.

Изначально генерация запускалась из PHP скрипта, примерно так:

<?php
// локальный файл
exec('xvfb-run python2 html2pdf.py file:///tmp/in.html /tmp/out.pdf');
// или URL
exec('xvfb-run python2 html2pdf.py http://habrahabr.ru /tmp/habr.pdf');
?>

этого было достаточно и все было хорошо…

Очень часто в программах приходится использовать многопоточность. Иногда это монстрообразные пулы потоков со сложным взаимодействием, но гораздо чаще это бывает простой код, главное требование к которому — не замораживать интерфейс.

Всем хорош GTK+, но наблюдается большая проблема с работой его с потоками. Сам по себе GTK является thread-safe, но требуя принудительной блокировки со стороны пользователя. Вторая проблема заключается в том, что блокировка реализована через мутексы, и вы должны вызывать блокировку строго один раз, иначе ваш код «зависнет» на linux, прекрасно при этом работая на windows.

При написании программ на Python, используя при этом графический интерфейс иногда приходится запускать различные долгие обработки каких либо данных, при этом в большинстве случаев будет блокироваться интерфейс и пользователь увидит программу замороженной. Чтобы этого избежать необходимо нашу задачу запустить в параллельном потоке или процессе. В данной статье мы рассмотрим, как это сделать в wxPython с помощью модуля Threading.

Потокобезопасные методы wxPython

В wxPython существуют три метода для работы с потоками. Если ими не пользоваться, то при обновлении интерфейса программы Python могут подвиснуть. Чтобы этого избежать, необходимо использовать потокобезопасные методы: wx.PostEvent, wx.CallAfter и wx.CallLater. По словам Robin Dunn (создатель wxPython) wx.CallAfter использует wx.PostEvent для отправки события на объект приложения. Приложение будет иметь обработчик этого события и будет реагировать на него соответственно заложенному алгоритму. На сколько я понимаю wx.CallLater вызывает wx.CallAfter с заданным параметром времени, чтобы он знал сколько ему ждать перед отправкой события.

Robin Dunn также отметил, что Global Interpreter Lock (GIL) не допустит одновременного выполнения более одного потока, что может ограничить количество используемых ядер процессора. С другой стороны, он также сказал, что wxPython освобождается от GIL вызывая API функции библиотеки wx, поэтому другие потоки могут работать одновременно. Другими словами быстродействие может изменяться при использовании потоков на многоядерных машинах. Обсуждение этого вопроса может быть интересным и не понятным…
Прим. перев. — для более полного знакомства с GIL прошу сюда.

Наши три метода можно разделить на уровни абстракции, wx.CallLater находится на самом верху, далее идет wx.CallAfter, а wx.PostEvent находится на самом низком уровне. В следующих примерах вы увидите, как использовать wx.CallAfter и wx.PostEvent в программах WxPython.

Маленькая преамбула:

Давно хотел поднять эту тему, но лезть в рассылку или irc-канал пока не хочу, поэтому давайте попробуем убить двух зайцев:
1) я напишу маленькую статейку по использованию тред-контекстов с-апи питона.
2) задам вопрос гуру, если таковые есть.
Заодно эта статья будет полезна тем кто хочет узнать как работают нити в питоне и взаимодействуют между собой.

Итак о нитях и встроенном питоне:

Все я думаю рано или поздно что-нибудь и куда-нибудь встраивают, кто то бытовую технику в кухню, ну а кто-то скриптовые языки программирования в свою программу. Иногда эта процедура легка и безболезненна, особенно в одно-поточных программах. Посудите сами: инициализировал интерпретатор, создал биндинги, выполнил скрипт, получил результат. Впрочем бывают не столь простые случаи, особенно если ваше приложение требует не блокирующей работы и/или нитей.

Специально для таких случае в с-питоне сделали тред-контексты: структуры для хранения глобального состояния интерпретатора. Именно они являются основой работы тредов и GIL-а при многопоточной работе.

Теперь несколько моментов по поводу инициализации интерпретатора для работы с нитями. К сожалению я не стал включать сюда курс по встраиванию питона, благо он отлично описан прямо в документации(Встраивание питона в приложения на английском). Вместо этого я расскажу о тонкостях использования и работы с тред-контекстами. Так же если вы с питоном хотя бы на «сделай мне это, пожалуйста», то вы знаете о том что GIL не позволяет питону выполнять несколько потоков одновременно, блокируя конкурирующие потоки до тех пор пока GIL не будет отпущен. В среднем любой сишный модуль к питону, будь то математика или дисковое IO или сеть отпускает GIL чуть более чем дофига раз за свою работу. То есть GIL не гарантирует что во время выполнения одной нити, будут спать все остальные. Это очень важный момент для того кто решит встраивать питон и делать много нитей. И уж точно не стоит надеяться на то что ваш поток выполнится за один присест.

Хабы: Python

Недавно появилась необходимость и желание ознакомится с PyGTK. Литературы на русском по данному вопросу практически нет, а то, что находит гугл в разных блогах — бывает немного устаревшим. Также с удивлением обнаружил, что и на хабре тема PyGTK не особо популярна.

Итак, не буду рассказывать про компоновку элементов интерфейса, ибо такие статьи уже есть. Расскажу про следующий шаг: создание приложения, которое выполняет некую работу, в процессе отображая свой прогресс.
Читать дальше →