Python-сообщество

Проясните плиз кто знает.
В доке написано

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
Не гарантируется блокировка очереди для get(), put(), которые будут идти следующими в коде.
Т.е. сам по себе вызов проверки наличия элементов в очереди ничего не блокирует и не резервирует место в очереди или первый элемент в очереди, что вполне логично. Блокировка происходит позднее, когда вызывается get(), put().

В любом случае, хотелось бы услышать какая стоит задача, которая предполагает, что в коде
if q.empty():
some_work_with_put()
else:
another_work_with_get()
после 1 строки вам нужно боятся переполнения очереди.

пасиба, я въехал

была задача которая предполагала

if not q.empty():
some_work_with_get()

bazooka
была задача которая предполагала

Отредактировано (Фев. 4, 2010 14:26:15)

bazooka
if not q.empty():
some_work_with_get()

Lexander
Разве система настолько была настолько нагружена, имела несколько независимых читателей очереди, что была возможность коллизии?
Это я к тому, что на самом деле существует не так уж много задач, которые требуют отдельной проработки операций с очередью.

ZZZ
Queue.Queue, это очень удобный инструмент. Да, иногда его использовать избыточно, но довольно часто это просто удобно.

ZZZ
Плохая идея. Лучше обрабатывать исключение Queue.Empty – по крайней мере это более логично и потокобезопасно.

Всё нормально. У меня такие задачи были. И не раз.

Есть четыре варианта, когда очередь жизненно необходима:
1. Несколько потоков добавляют в очередь данные и один поток берёт их по-одному для обработки;
2. Один поток пишет данные в очередь и несколько потоков берут эти данные для обработки;
3. Один к одному;
4. Много ко многому (в моей практике не встречалось).

Lexander
И даже больше - это реально просчет проектирования.

ZZZ
Всё нормально. У меня такие задачи были. И не раз.

Есть четыре варианта, когда очередь жизненно необходима:
1. Несколько потоков добавляют в очередь данные и один поток берёт их по-одному для обработки;
2. Один поток пишет данные в очередь и несколько потоков берут эти данные для обработки;
3. Один к одному;
4. Много ко многому (в моей практике не встречалось).

Он правильный тем, что будет работать, но не очень правильный с точки зрения стилистики. ИМХО.
Всё-таки операции get и put нужно обрамлять в try…except, чтобы потом, когда захочется добавить ещё поток, не поймать странных, трудноуловимых, глюков.

ZZZ
Он правильный тем, что будет работать, но не очень правильный с точки зрения стилистики. ИМХО.
Всё-таки операции get и put нужно обрамлять в try…except, чтобы потом, когда захочется добавить ещё поток, не поймать странных, трудноуловимых, глюков.