Queue.empty()т.е там не гарантируется ниче, нафиг тогда этот метод? Можно ли им все-таки проверять незаполненость?
Return True if the queue is empty, False otherwise. If empty() returns True it doesn’t guarantee that a subsequent call to put() will not block. Similarly, if empty() returns False it doesn’t guarantee that a subsequent call to get() will not block.
def worker():
while True:
item = q.get()
do_work(item)
q.task_done()
bazookaРазве система настолько была настолько нагружена, имела несколько независимых читателей очереди, что была возможность коллизии?
была задача которая предполагала
bazookaПлохая идея. Лучше обрабатывать исключение Queue.Empty – по крайней мере это более логично и потокобезопасно.
if not q.empty():
some_work_with_get()
LexanderQueue.Queue, это очень удобный инструмент. Да, иногда его использовать избыточно, но довольно часто это просто удобно.
Разве система настолько была настолько нагружена, имела несколько независимых читателей очереди, что была возможность коллизии?
Это я к тому, что на самом деле существует не так уж много задач, которые требуют отдельной проработки операций с очередью.
ZZZВ моем предложении еще было слово “отдельной” и я не отговаривал (или удивлялся) от использования очереди ;)
Queue.Queue, это очень удобный инструмент. Да, иногда его использовать избыточно, но довольно часто это просто удобно.
ZZZУ вас были проекты, в которых чтение из очереди производилось из разных потоков?
Плохая идея. Лучше обрабатывать исключение Queue.Empty – по крайней мере это более логично и потокобезопасно.
LexanderС чего это? Я очень люблю нити и постоянно их использую, и само собой, мне нужны средства для их синхронизации. Иногда это просто лок, иногда семафор… Но чаще всего именно очередь. И это удобно.
И даже больше - это реально просчет проектирования.
ZZZВот именно.
Всё нормально. У меня такие задачи были. И не раз.
Есть четыре варианта, когда очередь жизненно необходима:
1. Несколько потоков добавляют в очередь данные и один поток берёт их по-одному для обработки;
2. Один поток пишет данные в очередь и несколько потоков берут эти данные для обработки;
3. Один к одному;
4. Много ко многому (в моей практике не встречалось).
ZZZНу, в общем то ваша мысль понятна, хотя я не разделяю этой предусмотрительности “на вырост” при заранее известном ТЗ :)
Он правильный тем, что будет работать, но не очень правильный с точки зрения стилистики. ИМХО.
Всё-таки операции get и put нужно обрамлять в try…except, чтобы потом, когда захочется добавить ещё поток, не поймать странных, трудноуловимых, глюков.