История изменений

Почему непригоден?

Я уже не вспомню конкретику. У меня была модель мастер→процессы-обработчики→обратно в мастер, и я намучился просто феерически, потому что примитивы mp не умели базовые вещи для этого необходимые. То прерывание работы нормально не обработать, то конец очереди не отловить, то не заблокироваться когда очередь переполнена, то не уничтожить нормально непустую очередь из которой никто уже не читает, то дедлок в мастере, который очень сложно обходится, что-то из этого класса проблем, разнообразное и обильное.

И, если дочерние процессы создавать вручную, то не возникнет ли проблем с отладкой?

Я не пользуюсь отладкой, так что не знаю. Попробуйте, там нет никакой магии - mp на том же форке и пайпах и построен.

На данный момент mp.Pipe удобен тем, что сам делает и pickle/unpickle и чтение из такой «трубы» просто возвращает объект. При ручной работе с pipe/socket надо будет самому велосепедировать pickle/unpickle или есть что-то готовое?

Вам же нужно взаимодействие с не-питон процессами, какой там пиклинг? А так, это либо обёртка на 10 строчек, или добавление pickle()/unpickle() в write/read. Ну либо конкретно здесь и mp.Pipe сгодится. Без остального mp.

А что в этом плохого?

Как минимум, непереносимо в целом и привязывает к сокетам не unix, когда вполне хватило бы пайпов. Есть подводные камни, что-то там в man было про передачу закрытого дескриптора. Для высокоуровневых языков нужны дополнительные телодвижения для развёртывания высокоуровневого примитива для вытаскивания дескриптора на одной стороне и обратного процесса на другой. В конце концов, файловые дескрипторы это приватный ресурс процесса, и любые попытки их шаринга и передачи - нарушение инкапсуляции, усложнение архитектуры и сад граблей.

Почему непригоден?

Я уже не вспомню конкретику. У меня была модель мастер→процессы-обработчики→обратно в мастер, и я намучился просто феерически, потому что примитивы mp не умели базовые вещи для этого необходимые. То прерывание работы нормально не обработать, то конец очереди не отловить, то не заблокироваться когда очередь переполнена, то не уничтожить нормально непустую очередь из которой никто уже не читает, что-то из этого класса проблем, разнообразное и обильное.

И, если дочерние процессы создавать вручную, то не возникнет ли проблем с отладкой?

Я не пользуюсь отладкой, так что не знаю. Попробуйте, там нет никакой магии - mp на том же форке и пайпах и построен.

На данный момент mp.Pipe удобен тем, что сам делает и pickle/unpickle и чтение из такой «трубы» просто возвращает объект. При ручной работе с pipe/socket надо будет самому велосепедировать pickle/unpickle или есть что-то готовое?

Вам же нужно взаимодействие с не-питон процессами, какой там пиклинг? А так, это либо обёртка на 10 строчек, или добавление pickle()/unpickle() в write/read. Ну либо конкретно здесь и mp.Pipe сгодится. Без остального mp.

А что в этом плохого?

Как минимум, непереносимо в целом и привязывает к сокетам не unix, когда вполне хватило бы пайпов. Есть подводные камни, что-то там в man было про передачу закрытого дескриптора. Для высокоуровневых языков нужны дополнительные телодвижения для развёртывания высокоуровневого примитива для вытаскивания дескриптора на одной стороне и обратного процесса на другой. В конце концов, файловые дескрипторы это приватный ресурс процесса, и любые попытки их шаринга и передачи - нарушение инкапсуляции, усложнение архитектуры и сад граблей.