[Python][multiprocessing]Singleton для нескольких процессов

у меня один вопрос, все таки процессы или потоки?
Потому что _процессы_ обьект шарить между собой никак не могут, только обмениваться информацией через пайп/DBus/и т.д.

да, именно процессы...

http://docs.python.org/library/multiprocessing#sharing-state-between-processes что ты сделать то хочешь конкретно?

Да, есть подозрение, что ты хочешь сделать что-то не то. Опиши задачу подробнее. Может, просто пайпы заюзать для передачи данных? а может, XMLRPC например ? а может, мультипроцессы не нужны? или, может, достаточно шарить файловый дескриптор? а может и общей памятью обойтись можно. непонятно же что там у тебя.

http://pypi.python.org/pypi/shm/0.1

Опиши не что есть, а что нужно. Пока складывается впечатление, что ты ССЗБ.

Здесь ответа нет? http://docs.python.org/dev/library/multiprocessing.html#exchanging-objects-be...

Не очень понятно, что ты хочешь получить, но зачем тебе синглтоны?
Не проще ли:
* запустилась программа
* подняла/запустила себе сервер
* пообщалась с ним по сокету
* погасила сервер
* завершила работу

???

Делай межпроцессное общение на пайпах и очередях.

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

Дёргать методы в multiprocessing у тебя вряд ли получится по другому.

Делай межпроцессное общение на пайпах и очередях.

Гм. Чем это отличается от multiprocessing?

ок, всем спасибо, что приняли участие в обсуждении.
пока сделал посредством выноса объекта-провайдера данных (который синглтон) в отдельный независимый сервер-демон, который реализует свой сетевой протокол уровня приложения, то есть, немного более упрощённый xml-rpc, и к которому коннектятся порождённые процессы.
Зачем мне это нужно было - я не хотел что бы уровнем доступа к данным обладали и порождённые процессы, так как их основной задачей было только обрабатывать полученные данные из БД, и дальше согласно только своей задачи, а пораждать в каждом сабпроцессе объекты, которые работают с БД, и прочими слоями моего скрипта, имхо затратно и ресурсоёмко.
В общем, всем спасибо!

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

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

только обрабатывать полученные данные из БД, и дальше согласно только своей задачи

Почему не подошел Pool? Мастер процесс выбирает данные и скармливает их воркерам.

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

Опять таки, что мешает сделать инициализацию один раз на достаточно долгоживущий воркер?

>Гм. Чем это отличается от multiprocessing?

Так это, для мультипроцессинга как раз и предлагаю. Я про мультипроцессинговые пайпы.

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

>и в таком случае, если происходит одновременная запись несколькими процессами в один конец пайпа,

Так по пайпу на процесс. Кладёшь их в массив в главном процессе, и обходишь его. С локом по таймауту.

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

Таймаут, таймаут.

А в конце работы подпроцессов слать какой-нибудь специальный код, которые будет вызывать закрытие пайпа. Эдакая event-driven фигня получается.

оканчивает работу один, сразу запускается второй

Что мешает сделать воркер постоянно работающим?

P.S. Мне кажется, ты нихрена не понял сути multiprocessing.

Кладёшь их в массив в главном процессе и обходишь его.

Можно сделать очередь готовности.