multiprocessing.pool не то, что вам нужно в этом случае - это полезно для выполнения нескольких единиц работы «в фоновом режиме» (одновременно), а не для управления общим ресурсом. Поскольку у вас, кажется, есть отработанный формат сообщений, и они общаются только в одном направлении, вам нужен multiprocessing.Queue - документация имеет хороший пример того, как его использовать - вы будете хотите, чтобы ваш Process_1 помещал данные в очередь по мере необходимости, а Process_2 вызывал q.get () в бесконечном цикле. Это заставит потребителя блокировать, когда делать нечего, вместо того, чтобы ждать, как вы предлагаете (что может тратить циклы процессора). Проблема, которую он оставляет, заключается в закрытии демона - возможно, лучший способ состоит в том, чтобы продюсер поместил значение часового в конец очереди, чтобы гарантировать, что получатель обрабатывает все запросы. Другие альтернативы включают такие вещи, как попытка принудительно завершить процесс при выходе из дочернего процесса, но это подвержено ошибкам.
Обратите внимание, что это предполагает, что Производитель порождает Потребителя (или наоборот) - если Потребитель является долгосрочным демоном, который может иметь дело с несколькими относительно недолговечными Производителями, ситуация становится немного более сложной - нет t, насколько мне известно, любой кроссплатформенный высокоуровневый модуль IPC; самый переносимый (и, как правило, самый простой) способ справиться с этим может заключаться в использовании файловой системы в качестве очереди - иметь папку спулинга где-нибудь, куда производители пишут текстовый файл для каждого запроса; Потребитель может затем обработать их на досуге - однако, это не без его собственных проблем: вам нужно было бы убедиться, что Потребитель не пытается открыть наполовину написанный файл инструкции, что Производители не наступают пальцы друг друга, и что производители и потребители согласовывают порядок запросов.