Как расшариваются данные между процессами

Что проверяют

Понимаете ли вы, что у процессов в Python память раздельная и любой обмен данными стоит сериализации или явной разделяемой памяти. Следом обычно спрашивают, почему для CPU-задач берут процессы, а не потоки, и что меняет метод запуска fork или spawn.

Как отвечать

Пройдитесь по инструментам multiprocessing от удобных к быстрым:

• Queue: очередь с блокировками внутри, объекты пиклятся и идут через канал. Удобно для задач и результатов, медленно для больших массивов;
• Pipe(): пара соединений между двумя процессами, по умолчанию двунаправленная. Быстрее очереди, но рассчитана ровно на двух участников;
• Value и Array: типизированные данные на ctypes в разделяемой памяти. У них есть встроенный лок, но v.value += 1 не атомарна, её надо оборачивать в with v.get_lock():;
• shared_memory.SharedMemory (с Python 3.8): именованный блок памяти, поверх которого удобно создать массив NumPy без копирования. Блок нужно закрыть через close() в каждом процессе и один раз удалить через unlink();
• Manager: отдельный серверный процесс с прокси к dict и list. Гибко, но каждое обращение это межпроцессный вызов с сериализацией.

Упомяните метод запуска: при fork потомок получает копию памяти родителя по copy-on-write, при spawn стартует чистый интерпретатор, и всё передаваемое должно пиклиться. На macOS и Windows по умолчанию spawn, на Linux с Python 3.14 по умолчанию forkserver. Для обмена между машинами или независимыми сервисами берут Redis, брокер или сокеты.

Где спотыкаются

Думают, что изменённая после fork глобальная переменная видна в другом процессе. Каждый процесс меняет свою копию.

Делают join() до того, как вычитали очередь. Процесс не завершится, пока его данные не ушли из буфера очереди, и программа виснет.

Передают через Pool.map огромные объекты на каждую задачу и удивляются, что параллельная версия медленнее последовательной: всё время уходит на пиклинг.