День добрый. Есть такая архитектура программы (менять нельзя):
- Есть главный процесс, в нем интерфейс (PyQt и Web-шлюз) и управление другими процессами.
- Есть дочерние процессы, обрабатывающие задачу. Они порождаются главным процессом. Как именно порождаются (exec, fork ) - не важно.

Нужно обеспечить достаточно тесный уровень взаимодействия между главным и дочерними. 
1) Главный процесс может менять параметры обработки, посылая довольно большой список значений (словарь с параметрами)
2) Главный процесс должен в своем интерфейсе показывать что творится дочерних, то есть несколько раз в секунду получать от них массивы с информацией для показа оператору.
3) Главный процесс может быть уничтожен оператором а потом вновь запущен, надо возобновить управление запущенными дочерними (информация и PIDы дочерних можно хранить в БД, искать процессы в ОС не надо  )

Посоветуйте плз., какой механизм взаимодействия тут лучше всего применить? 
 - Именованные каналы - долго, так как это все будет через физические файлы (поправьте меня, если ошибаюсь)
 - Анонимные каналы (pipe) - не сохранятся при рестарте главного процесса
 - Через БД (ну допустим таблица с переменными) - еще дольше чем через каналы-файлы, нагрузка думаю будет очень высока
 - Из рассмотренных вариантов есть еще модуль mmap, пока не работал с ним, решил сначала спросить совета. Кстати, он допускает рестарт одного из процессов?
 - Можно через sockets - вроде неплохой вариант

В общем прошу совета, кто решал подобную задачу, как тут удобней всего сделать.
Спасибо


Это сообщение отредактировал(а) VinniPuhh - 10.5.2012, 12:43

Все это велосипеды, тебе нужен обычный диспетчер сообщений. ZeroMQ быстрейший из них, но порог вхождения довольно высок. Почитай документацию по нему, многих велосипедистов она буквально "просветляет".

А ещё есть lcm  Он намного проще zeromq, но тоже достаточно мощный и шустрый, обеспечивает лёгкий и прозрачный объектный обмен между гетерогенными программами (например, на С и Java или на Python и С#).

VinniPuhh, слушай, а ты не смотрел модуль multiprocessing? Может он станет годной заменой твоим костылям?   

Это сообщение отредактировал(а) Ch0bits - 10.5.2012, 19:35

Спасибо, вкратце глянул на оба, очень впечатляет. Буду смотреть внимательней, хотя там больше на скорость обмена чем на удобство фокус, ну это imho.
Спасибо за советы.




Представляешь, смотрел  
Конечно вполне возможно что плохо смотрел, но я не знаю как используя этот модуль обеспечить пункт три задания "Главный процесс может быть уничтожен оператором а потом вновь запущен, надо возобновить управление запущенными дочерними". Походу там в принципе таких средств нет.  Если такая фишка есть (подключиться к уже запущенному ранее своему процессу, имея его PID и внутренний auth key (эти auth key сам модуль генерит)) - расскажи как, это разом снимет вообще все проблемы.

Не знаю какую ОС ты используешь, видимо линукс, но там убийство отца влечет смерть всех сыновый. Вообще конечно странное требование, ты уверен что без убийства отца не обойтись?


Может быть ты имел ввиду какой-нибудь внутренний id задачи, которую параллельно решают дети. Я не знаю характер приложения. Может быть этот id передавать через командную строку, например так управляются процессы google chrome.


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

Принцип KISS - keep it simple stupid! Не надо усложнять. Усложнение задачи в 2 раза усложняет её реализацию в 4 раза.

Это сообщение отредактировал(а) Ch0bits - 11.5.2012, 18:57

Странное утверждение....




[/quote]

Нет-нет, это именно сам модуль генерит, я надеялся что как раз для моего случая, но к сожалению ответа не нашел:
http://docs.python.org/library/multiprocessing.html






Ну смотри. Выполняется обработка большой задачи. Данные для обработки "куска" задачи берутся процессами из БД и интернета. Работают "сыновья" по нескольку часов, а то и суток. 
Оператор меняет там количество потоков обработки внутри каждого процесса, другие разные настройки.
Очень удобно, чтобы оператор закрыл управляющий интерфейс, а потом снова открыл и поменял что ему нужно.
Да, конечно, если бы все так как описано сейчас - писать тупо отчет о работе в БД, и оттуда же читать параметры. НО интерфейс - красивые графические окошки, в которых надо в реальном времени показывать чем занимается каждый поток. Через БД такое гонять - очень накладно.
Еще вариант - не "убивать" родителя по закрытию а просто спрятать форму. Но тогда неуниверсальна обработка через www-шлюз, там ребята на django пишут, надо чтобы этот django процесс коннектился к "сыновьям" а потом помирал... короче ТЗ сделано именно так из этих 3-х пунктов совершенно не зря  


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

PS Если кто в будущем будет сталкиваться - мы выбрали модель, что каждый порожденный процесс открывает для управления собой сокеты, и согласован протокол управления через них. Как это покажет себя в жизни - посмотрим