Почему multiprocessing.Queue имеет небольшую задержку, в то время как (по-видимому) multiprocessing.Pipe нет?

Question

Документация для multiprocessing.Queue указывает, что есть некоторая задержка с момента помещения элемента в очередь до его протравленного представления, сбрасываемого в нижележащий канал.Очевидно, что вы можете поместить элемент прямо в трубу (это не говорит об обратном и подразумевает, что это так).

Почему труба не нуждается - или не имеет - той же фоновой нити, чтобы сделать травление?И это та же самая причина, по которой нет аналогичной задержки при разговоре с multiprocessor.SyncManager.Queue?

(Бонусный вопрос: что означает документация, когда говорится «После помещения объекта в пустую очередь, может быть бесконечно малое задержка ... "? Я взял исчисление; я знаю, что означает бесконечно малое , и это значение здесь не подходит. Так о чем это говорит?)

Answer 1

Если вы записываете в Pipe, текущий поток блокирует до завершения записи.Следовательно, задержки нет (или, скорее, вызывающий поток не может их наблюдать), но возможно deadlock ;Pipe является инструментом более низкого уровня, чем Queue.

Ситуация с SyncManager.Queue заключается в том, что все запросы к менеджеру синхронизированы , так что процесс, который выдвигает объектзатем не может наблюдать, что он по-прежнему пуст (отсутствует всплывающее окно).

Между тем, «бесконечно малая» задержка означает просто задержку планирования потока, а не (возможно, намного большее) время записи всего объекта: достаточночтобы запустил , чтобы установить, что Queue не пустой.Тем не менее, толкающая нить может выиграть гонку и наблюдать, что ей по-прежнему не хватает объекта, «уже выдвинутого».