LINUX.ORG.RU

[python] Как бы эдак реализовать обмен данными между программами?


0

1

Допустим есть две программы А и Б.

Программа А единственное, что делает - это преобразует некоторые данные и после их манипуляции выдает на выход измененные наборы данных. Данные программа может выдавать раз 20 за секунду, а могут 3-4 за минуту.

Программа Б занимается дальнейшим преобразованием данных, полученных из программы А.

Так вот вопрос - как бы грамотнее сделать взаимодействие этих программ? Пока что смотрю в сторону D-Bus, с одной стороны похоже что оно-то как-раз и надо, но с другой стороны не знаю на сколько практичное решение этот D-bus

★★★★★

> Программа А единственное, что делает - это преобразует некоторые данные и после их манипуляции выдает на выход измененные наборы данных. Данные программа может выдавать раз 20 за секунду, а могут 3-4 за минуту.

progA | progB

Пока что смотрю в сторону D-Bus

Песец.

tailgunner ★★★★★ ()

слушать/читать юнегз-сокеты как вариант

anonymous ()

MQ? Например AMQP, например, RabbitMQ?

Через HTTP/JSON?

Через какой-то RPC? DCOM? CORBA?

Macil ★★★★★ ()

Пайпы решают порблему практически идеально. Через Popen в программе Б запускаем прогрмамму А и далее по тексту.

Ну если совсем хочется странного, то ZeroMQ сокеты.

mashina ★★★★★ ()

только corba, только хардкор! (шутка)

по делу - сказали уже: пайпы, сокеты.

aol ★★★★★ ()

В модуле multiprocessing есть queue. Может подойдет.

Данные программа может выдавать раз 20 за секунду

Нет, dbus тут явно не подходит.

AST-PM-105 ()

>Пока что смотрю в сторону D-Bus

Cурово.

aedeph ()
Ответ на: комментарий от mashina

>Пайпы решают порблему практически идеально. Через Popen в программе Б запускаем прогрмамму А и далее по тексту.

Ну так то оно решает, только вот хочу чтобы было устроено так, что если появится еще и программа В - то они обе смогли бы подключиться к одному экземпляру А.

Siado ★★★★★ ()
Ответ на: комментарий от erfea

УМВР. Например, сервер выкладывает в 4 shm-буфера видео, а в пятый - номер текущего буфера. Клиенты забирают картинку из текущего буфера. Все ОК. Главное, про мьютексы/семафоры или другие подобные блокировки не забывать при чтении пятого буфера. Хотя в конкретной задаче это не важно.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

> Например, сервер выкладывает в 4 shm-буфера видео, а в пятый - номер

текущего буфера. Клиенты забирают картинку из текущего буфера.


Интересный алгоритм. Спасибо.

Примерно как переключение цветовых плоскостей в VGA-/EGA-адаптерах и экранов в OpenGL.

pacify ★★★★★ ()
Ответ на: комментарий от pacify

>> Например, сервер выкладывает в 4 shm-буфера видео, а в пятый - номер

текущего буфера. Клиенты забирают картинку из текущего буфера.


Интересный алгоритм. Спасибо.


Ring buffer. Welcome to club!

mv ★★★★★ ()
Ответ на: комментарий от pacify

Ну, это стандартный механизм работы v4l2 при буферизации в буферы пользователя.

Нужно лишь подготовить эти буферы и пятый буфер, в котором будет находиться номер актуального на данный момент времени.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Siado

емнип от zmq профит будет только если у тебя не одна машина, shm вообще хранится у тебя в озу и не просит сеть\винтчестер

bhfq ★★★★★ ()
Ответ на: комментарий от Eddy_Em

а как клиенты будут оповещаться о заполнении буфера? вариант «проверять N раз в секунду» ущербен, вариант «dbus» ущербен. разве что юникс-сокеты таки подключать.

jcd ★★★★★ ()
Ответ на: комментарий от jcd

Вы про видео? Там же циклический буфер. Отобразили картинку, проверили номер текущего буфера - если тот же самый, подождали. Здесь оповещения не нужны.

А в задачах ТСа т.к. клиент - один, можно, например, использовать сигналы, или flock на shm-файл, или очередь сообщений - да что угодно. Механизмов rpc полным-полно!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

>подождали

про то и спрашиваю - до каких пор ждем?

сигналы


очередь сообщений


интересно, через что будет удобнее реализовать

jcd ★★★★★ ()
Ответ на: комментарий от Siado

>Ну так то оно решает, только вот хочу чтобы было устроено так, что если появится еще и программа В - то они обе смогли бы подключиться к одному экземпляру А.

MQ выше уже советовали.

JFreeM ★★★☆ ()
Ответ на: комментарий от jcd

про то и спрашиваю - до каких пор ждем?

Пока не появится следующий кадр. Либо пока программа не получит SIGHUP. Я исходники вроде выкладывал (вот старая версия на гуглокоде). Если нет, могу выложить. Только вряд ли вам этот быдлокод будет интересен.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Siado

Ну так то оно решает, только вот хочу чтобы было устроено так, что если появится еще и программа В - то они обе смогли бы подключиться к одному экземпляру А.

ну тогда прямая дорога к zmq

mashina ★★★★★ ()
Ответ на: комментарий от Siado

Прочитал про zmq тоже штука хороша. А если в сравнении - что быстрее, передавать через shm или через zmq ?

Это зависит от многих тонкостей и для питона не прилично задавать такие вопросы. Ещё лучше задаться другим вопросом - что будет легче понять и заботать? Вот c shm гарантированно получишь вагон гемора, особенно если делаешь это первый раз и не искушён ipс своими руками.

Грубо говоря, zmq сделает примерно тоже самое, что ты будешь делать с shm, только тебе ещё придётся это придумать.

мнип от zmq профит будет только если у тебя не одна машина, shm вообще хранится у тебя в озу и не просит сеть\винтчестер

zmq использует тот же shm как один из вариантов ipc. И локальные юникс сокеты (тоже вариант ipc для zmq) на «юниксах» тоже бесплатны.

mashina ★★★★★ ()
Ответ на: комментарий от Eddy_Em

во-первых, shm != разделяемая память, а разделяемая память != shm. Существуют более няшные способы поиметь рязделяемую память между процессами.

И во-вторых,

Разделяемая память - самый удобный способ общения неродственных процессов.

совсем неправда. Самый _удобный_ способ это пайпы и юникс сокеты если из стандартных средств брать.

mashina ★★★★★ ()
Ответ на: комментарий от mashina

Самый _удобный_ способ это пайпы и юникс сокеты

Которые реализуются через «ядреную» разделяемую память :)

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от mashina

>Это зависит от многих тонкостей и для питона не прилично задавать такие вопросы. Ещё лучше задаться другим вопросом - что будет легче понять и заботать? Вот c shm гарантированно получишь вагон гемора, особенно если делаешь это первый раз и не искушён ipс своими руками.

Не вижу никакого гемора у обоих способов. У zmq в питоне все элементарно и понятно, код не более чем несколько строк. У shm аналогично, не вижу где там можно гемор получить, если одна прога пишет в файл и несколько прог считывают его =)

Siado ★★★★★ ()

Ох, ребята. Ну прямо ниибаца иксперты и орхитектыри, я извиняюсь. Закидали топикстартера ответами различной степени релевантности, и при этом умудрились не задать два самых главных вопроса:

1) Программы А и Б работают на одной машине, или же на разных? Возможно ли в будущем распределенное развертывание? Это существенным образом повлияет на выбор local IPC vs. remote IPC.
2) Программа А выплевывает данные синхронным или асинхронным образом? То есть, грубо говоря, есть ли необходимость получить от программы Б подтверждение того, что данные получены и (возможно) обработаны.

Одно тут ясно, текстовые протоколы (SOAP, XMLRPC, REST/JSON) слабо релевантны в силу как большого оверхеда по передаваемым данным, так и в силу относительно больших расходов на парсинг. Есть области, где веб-сервисы незаменимы, но это явно не тот случай.

Kuka ★★ ()

В любом случае, рекомендую изучить, как устроен RPC между компонентами Deluge (deluged и собственно GUI). Требованиям вполне удовлетворяет.

Kuka ★★ ()
Ответ на: комментарий от Kuka

>Одно тут ясно, текстовые протоколы (SOAP, XMLRPC, REST/JSON) слабо релевантны в силу как большого оверхеда по передаваемым данным, так и в силу относительно больших расходов на парсинг. Есть области, где веб-сервисы незаменимы, но это явно не тот случай.

Еще раз перечитал тред и так и не понял, почему ТСу не подойдут текстовые протоколы?

Waterlaz ★★★★★ ()
Ответ на: комментарий от Waterlaz

> почему ТСу не подойдут текстовые протоколы?

Текстовые протоколы оправданы а) в случае интеграции распределенных гетерогенных систем (например, Java <-> .NET), б) в случаях, когда контракт между системами хорошо описан, но требуется расширяемость, в) для достижения слабой «завязанности» (low coupling) компонентов, г) когда есть профит от употребления расширений WS-I (транзактность, security и т.п.) При этом оверхед на конструирование/разбор сообщений и оверхед по данным являются оправданными.

Ни одного подобного требования от ТСа не прозвучало. Впрочем, от него вообще пока мало чего прозвучало :) Предлагаю дождаться его ответов на вышеприведенные вопросы, а потом уже что-то предлагать.

Kuka ★★ ()
Ответ на: комментарий от Kuka

Текстовые протоколы оправданы а) в случае интеграции распределенных гетерогенных систем...

в детсад с такой ахинеей.

mashina ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.