Потоки - это не единственный способ использования многозадачности в языке Python. В действительности процессы обладают некоторыми преимуществами перед потоками, т. к. они, в отличие от потоков в языке Python, могут вbinолняться на разных процессорах. На самом деле, из-за наличия глобальной блокировки интерпретатора (global Interpreter Lock, GIL) в каждый момент времени может вbinолняться только один поток управления и только на одном процессоре. Поэтому для решения «тяжеловесных» задач на языке Python потоки являются не лучшим выбором. В таких случаях обработку лучше производить в разных процессах.

Процессы будут лучшим выбором, если для решения задачи потребуется задействовать несколько процессоров. Кроме того, существует множество библиотек, которые просто не могут работать с потоками управления. Например, текущая реализация библиотеки Net-SNMP для языка Python не является асинхронной, поэтому при необходимости выполнения параллельной обработки следует использовать ветвление процессов.

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

Ранее мы упоминали альтернативный метод создания множества процессов, основанный на использовании функции subprocess. Popen(). Во многих случаях это отличный выбор для организации параллельного выполнения программного кода.

Как упоминалось ранее, реализация параллельной обработки данных никогда не отличалась простотой. Этот пример можно было счесть неэффективным, потому что в нем используется функция subprocess. Popen(), вместо того чтобы с помощью модуля processing создавать дочерние процессы, в которых вызывать функцию subprocess.call(). Однако с точки зрения крупного приложения использование прикладного интерфейса, напоминающего очереди, имеет свои преимущества и сравнимо с примером многопоточного приложения, приведенного выше. В настоящее время идут разговоры об объединении модулей processing и subprocess, потому что модулю subprocess недостает возможности управления группой процессов, которая присутствует в модуле processing. Этот запрос был сделан в системе PEP (Python Enhancement Proposal - система приема предложений по улучшению Python) для модуля subprocess: http://www.py-thon.org/dev/peps/pep-0324/.

Set as favorite

Bookmark

Email This

Hits: 293

Комментарии (0)

RSS feed Comments

Написать комментарий

Имя

Электронный адрес

Вебсайт

Заголовок

Комментарий

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Добавить комментарий