Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Перенесите в блог по питону, когда кармы наберете (а вы наберете :) ). Хороший материал.
Как раз искал. Спасибо за статью.
P.S.: Заметил странность — слово «многопоточность» в программировании встречается столько же, сколько «позиционирование» в маркетинге.
P.S.: Заметил странность — слово «многопоточность» в программировании встречается столько же, сколько «позиционирование» в маркетинге.
Насчет полезности мне трудно уже судить, поэтом побрюзжу:
0. Зачем использовать print для вывода отладочной информации, когда есть простой и удобный logging;
1. Threading это всеже нити. Для работы с многопоточностью есть multiprocessing;
2. Для практического применения прокси на тредах не годится (или только при мизерных нагрузках).
0. Зачем использовать print для вывода отладочной информации, когда есть простой и удобный logging;
1. Threading это всеже нити. Для работы с многопоточностью есть multiprocessing;
2. Для практического применения прокси на тредах не годится (или только при мизерных нагрузках).
0) print работает исключительно как индикатор
1) Под Threading подразумевал именно нити (по поводу путаницы с терминологией я предупреждал)
2) Что именно подразумевается под практическим применением?
1) Под Threading подразумевал именно нити (по поводу путаницы с терминологией я предупреждал)
2) Что именно подразумевается под практическим применением?
1) Threads — это потоки, в некоторых переводах «нити». Мне много больше нравятся потоки, так как они хоть что-то означают. Путаницы с I\O потоками (те что streams) тут совсем нету. Multiprocessting — это чуть другое. Об этом можно почитать в POSIX модели процессов и потоков.
А вообще можно переводить Threads как угодно, но учтите, что очень много программистов никогда и не слышали о нитях.
З.Ы. А как перевести multithreading?
А вообще можно переводить Threads как угодно, но учтите, что очень много программистов никогда и не слышали о нитях.
З.Ы. А как перевести multithreading?
А что вы скажете про Stackless?
ааа, спасибо огромное! как раз задумался над таким парсингом. завтра перепишу парочку своих скриптов
1. В 2.5 питоне тоже есть with statements: from __future__ import with_statement
2. Не хватает дисклеймера со словами «естественно, я понимаю, что писать многопоточный парсер google.com — затея не из лучших»
Кстати, работу с локами тоже проще завернуть в with ;)
2. Не хватает дисклеймера со словами «естественно, я понимаю, что писать многопоточный парсер google.com — затея не из лучших»
Кстати, работу с локами тоже проще завернуть в with ;)
Мне одному кажется что вы переборщили с комментариями? По мне так лучше пусть было бы
красиво написанноеи откомментированное в несколько раз менее объемно.
Надо было добавить ещё код с молдавскими комментариями ))
Есть вопрос. Не уверен, что автор сможет дать ответ, но может кто-то:
Правильно ли я понял, RLock & Lock это аналоги recursive mutex & non-recursive mutex из POSIX thread model?
Правильно ли я понял, 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):
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
Что будет с вашими потоками, если отвалиться сеть, или гугл начнет отдавать 404? Они повиснут, т.к очередь никогда не отчиститься.
Что будет, если кончится место на диске? Потоки зависнут, т.к после взятия лока вылетит исключение на open(), и лок уже не будет освобожден.
То, что код работает и в нем много комментариев — не причина демонстрировать его, называя статью «основы работы с потоками».
Хороший пример работы с потоками — github.com/svetlyak40wt/couchdb-performance-tests/blob/master/couchdb_bulk_perf.py
Спасибо за ссылку, давно я искал чтоб было наглядно с очередью, свою писал. жесть.
о да, а если выключится компьютер, планета остановится, или того хуже — у меня закончится кофе! особенно интересно насчет окончания места на диске — вам не кажется, что в таком случае то уже и смысла нет в его дальнейшей работе как таковой (не, это не уменьшает моей быдлокодерской ошибки, но это факт). П.С. приведенный вами пример — это пример того, как я делать не буду.
особенно интересно насчет окончания места на диске — вам не кажется, что в таком случае то уже и смысла нет в его дальнейшей работе как таковой
конечно, в случае ошибки лучше наглухо зависнуть никому не сказать о причине
о да, а если выключится компьютер, планета остановится, или того хуже — у меня закончится кофе!
тогда и пишите во введении, что у вас пост про код с кучей концептуальных!!! багов (дедлок, это как раз концептуальный баг в многопоточной программе) а не про «понимания основных принципов работы многопоточных приложений»
Это же жесть:
___
Чем Вам BOOL помешал? или брослии бы исключение
Файлы и потоки это жесть номер два, я понимаю что это учебка. но изначально нужно закладывать правлиьное видение потоков, если у вас 1000 из 20000 и более потоянно.
по опыту скажу, что лучше «get_and_parse_page» делать не в потоке, у вас просто 100 проц. вермени будет сжираться от регекспа, т.е. я хотел сказать, что страницы нужно напарсить в потоках, тут все правльино, и дальше сделать генерарор, который будет в цикле, так вот по выходу из генератора все что накачали ( ну там 100 страниц допустим), уже делать регексп
вы соверенно не обрабатываете такие вещи как недоступность прокси, 403 от гугла и т.д. при такой схеме вас на 3-4 поток забанят ( пауза в 1 сек совершено бесполезна!) )( понимаю, что это пример, но вы хотябы в коментах про это отписали бы )
return «ERROR»
if parsed_data != «ERROR»:
___
Чем Вам BOOL помешал? или брослии бы исключение
Файлы и потоки это жесть номер два, я понимаю что это учебка. но изначально нужно закладывать правлиьное видение потоков, если у вас 1000 из 20000 и более потоянно.
по опыту скажу, что лучше «get_and_parse_page» делать не в потоке, у вас просто 100 проц. вермени будет сжираться от регекспа, т.е. я хотел сказать, что страницы нужно напарсить в потоках, тут все правльино, и дальше сделать генерарор, который будет в цикле, так вот по выходу из генератора все что накачали ( ну там 100 страниц допустим), уже делать регексп
вы соверенно не обрабатываете такие вещи как недоступность прокси, 403 от гугла и т.д. при такой схеме вас на 3-4 поток забанят ( пауза в 1 сек совершено бесполезна!) )( понимаю, что это пример, но вы хотябы в коментах про это отписали бы )
мне всегда нравились фразы типа: бла-бла, я здесь сделаю такую штуку, но вы такую штуку не делайте, я этого не рекомендую! :) зачем самому делать то что не рекомендуете?
а за топик спасибо, как раз сегодня хотел посмотреть что-то по работе с потоками
а за топик спасибо, как раз сегодня хотел посмотреть что-то по работе с потоками
Если вы про мой ответ, то я не рекомендовал делать в потоках регехп, так как он бесполезен в потоках, только нагружает проц, да еще если помножить на потоки, то получаеться как раз медленней, чем в прямой цикл поставить и обработать
А если вообще нафиг послать потоки в чтении страниц и просто асинхронно через epoll их тащить? Будет же вообще комильфо…
не я об этом говорил:
global queue
#Здесь и далее я буду обьявлять функции из глобального пространства
#имен в локальном для лучшей читабельности кода, хотя в написании
#софта такое делать строго не рекомендую (!)
global queue
#Здесь и далее я буду обьявлять функции из глобального пространства
#имен в локальном для лучшей читабельности кода, хотя в написании
#софта такое делать строго не рекомендую (!)
Не феншуйно читать комментарии, написанные под строкой, к которой они относятся. Обычно они сверху или в той же строке (pep8) и к этому все привыкли.
Как-то не очень с исключениями. Во-первых, except и сразу return может стоить вам многих часов, разбираясь почему «оно» не работает как как надо. Во-вторых, при работе с потоками (thread'ам), важно помнить две вещи — поток должен сам перехватывать свои собственные исключения и acquire/release должны быть обернуты try/finally или lock подсовывать with'у. Если write_to_file бросит исключение при открытии файла, будет и дедлок и необработанное иключение. Кстати print для иключения далеко не самый лучший индикатор, logging.exception поинформативней будет.
И еще, ENCODING то используется, то не используется.
И еще, 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()
Все, после того как третья очередь завершится основной поток выйдет и грохнет все висящие нитки.
в нитке остаётся только бесконечно крутить:
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()
Все, после того как третья очередь завершится основной поток выйдет и грохнет все висящие нитки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы работы с потоками в языке Python