Основы работы с потоками в языке Python

Перенесите в блог по питону, когда кармы наберете (а вы наберете :) ). Хороший материал.

Как раз искал. Спасибо за статью.

P.S.: Заметил странность — слово «многопоточность» в программировании встречается столько же, сколько «позиционирование» в маркетинге.

Насчет полезности мне трудно уже судить, поэтом побрюзжу:

0. Зачем использовать print для вывода отладочной информации, когда есть простой и удобный logging;
1. Threading это всеже нити. Для работы с многопоточностью есть multiprocessing;
2. Для практического применения прокси на тредах не годится (или только при мизерных нагрузках).

А что вы скажете про Stackless?

1. В 2.5 питоне тоже есть with statements: from __future__ import with_statement
2. Не хватает дисклеймера со словами «естественно, я понимаю, что писать многопоточный парсер google.com — затея не из лучших»

Кстати, работу с локами тоже проще завернуть в with ;)

Мне одному кажется что вы переборщили с комментариями? По мне так лучше пусть было бы

красиво написанное

и откомментированное в несколько раз менее объемно.

Надо было добавить ещё код с молдавскими комментариями ))

Есть вопрос. Не уверен, что автор сможет дать ответ, но может кто-то:
Правильно ли я понял, RLock & Lock это аналоги recursive mutex & non-recursive mutex из POSIX thread model?

зачем писать global? в вашем случае это вообще ни к чему

Если претендуете на академичность кода, то вот это пятна на нём:
try:
target_link = queue.get_nowait()
except Exception, error:
return

for _ in xrange(THREADS_COUNT):

Да, вы правы. У вас 100% говонокод.
Что будет с вашими потоками, если отвалиться сеть, или гугл начнет отдавать 404? Они повиснут, т.к очередь никогда не отчиститься.
Что будет, если кончится место на диске? Потоки зависнут, т.к после взятия лока вылетит исключение на open(), и лок уже не будет освобожден.

То, что код работает и в нем много комментариев — не причина демонстрировать его, называя статью «основы работы с потоками».

Хороший пример работы с потоками — github.com/svetlyak40wt/couchdb-performance-tests/blob/master/couchdb_bulk_perf.py

Это же жесть:

return «ERROR»
if parsed_data != «ERROR»:

___
Чем Вам BOOL помешал? или брослии бы исключение

Файлы и потоки это жесть номер два, я понимаю что это учебка. но изначально нужно закладывать правлиьное видение потоков, если у вас 1000 из 20000 и более потоянно.

по опыту скажу, что лучше «get_and_parse_page» делать не в потоке, у вас просто 100 проц. вермени будет сжираться от регекспа, т.е. я хотел сказать, что страницы нужно напарсить в потоках, тут все правльино, и дальше сделать генерарор, который будет в цикле, так вот по выходу из генератора все что накачали ( ну там 100 страниц допустим), уже делать регексп

вы соверенно не обрабатываете такие вещи как недоступность прокси, 403 от гугла и т.д. при такой схеме вас на 3-4 поток забанят ( пауза в 1 сек совершено бесполезна!) )( понимаю, что это пример, но вы хотябы в коментах про это отписали бы )

мне всегда нравились фразы типа: бла-бла, я здесь сделаю такую штуку, но вы такую штуку не делайте, я этого не рекомендую! :) зачем самому делать то что не рекомендуете?

а за топик спасибо, как раз сегодня хотел посмотреть что-то по работе с потоками

Не феншуйно читать комментарии, написанные под строкой, к которой они относятся. Обычно они сверху или в той же строке (pep8) и к этому все привыкли.

Как-то не очень с исключениями. Во-первых, except и сразу return может стоить вам многих часов, разбираясь почему «оно» не работает как как надо. Во-вторых, при работе с потоками (thread'ам), важно помнить две вещи — поток должен сам перехватывать свои собственные исключения и acquire/release должны быть обернуты try/finally или lock подсовывать with'у. Если write_to_file бросит исключение при открытии файла, будет и дедлок и необработанное иключение. Кстати print для иключения далеко не самый лучший индикатор, logging.exception поинформативней будет.

И еще, ENCODING то используется, то не используется.

Добавлю свои 5 копеек: некто не запрещает разделить задачу еще больше — сделать 3 очереди и 3 типа потоков (скачка, парсинг, сохранение). Это позволит начать обработку входных данных не дожидаясь окончательной их загрузки (если потоки запустить до начала загрузки данных в очередь) и сильнее разнести части кода (например для увеличения кол-ва разработчиков). Дальше можно нитки демонизировать, что позволит оставить их болтаться до тех пор пока не закончится основной поток. Забирать данные в этом случае можно и проще и надежнее:
в нитке остаётся только бесконечно крутить:
while True:
# забираем данные из очереди дожидаясь пока они там будут
data = queueN.get()
# делаем свое грязно дело
do_some_work(data)
# помечаем сделанную работу в очереди
queue.task_done()

в основной поток будет выглядеть примерно вот так:
queue1 = Queue()
queue2 = Queue()
queue3 = Queue()

# тип 1
for _ in range(NUMBER):
thread_ = threading.Thread(target=worker)
thread_.setDaemon(True) # для питона 2.5 (в 2.6+ есть обратносовместимый метод)
thread_.start()
# тип 2
for _ in range(NUMBER):
thread_ = threading.Thread(target=worker2)
thread_.setDaemon(True)
thread_.start()

# тип 3
for _ in range(NUMBER):
thread_ = threading.Thread(target=worker3)
thread_.setDaemon(True)
thread_.start()

# тут запихиваем в очереди данные, и по мере того как очередь будет наполнятся она начнет обрабатываться

# ждем когда закончатся все очереди
queue1.join()
queue2.join()
queue3.join()

Все, после того как третья очередь завершится основной поток выйдет и грохнет все висящие нитки.