LINUX.ORG.RU

Язык, активно использующий IPC Shared Memory без плясок с бубном?

 , ,


1

4

В заголовке - весь вопрос :)

Мне хотелось бы (как всегда невозможного?):

а) Не использовать файлы в любом виде для передачи данных между процессами

б) Не использовать MQ, in memory NoSQL, ... etc, etc

в) Использовать просто переменные языка, фактически находящиеся в shared memory и защищаемые mutex/semaphor'ами

г) Желательно, чтобы программа на языке «автомагически» умела чистить за собой созданные ею shared memory segment'ы при завершении дерева порождённых ею процессов. Возможно, стоит это делать в рамках cgroup'ы, но это уже досужие домыслы

Но главный вопрос всё-таки в том, умеет ли какой-либо язык программирования безо всяких явных сериализаций/десериализаций хранить в Shared Memory свои переменные?

Заранее сурово признателен! :)

★★★★★

Ответ на: комментарий от i-rinat

«Не-не-не, Девид Блейн»

Очень часто нужно разделять 1% всех переменных между процессами, остальные должны быть изолированы. Ну и вообще как-то спокойнее жить и работать, зная, что живёшь за железной дверью, но можешь вынимать контракты на убийство из почтового ящика в подъезде и отчитываться о результатах в этот же почтовый ящик.

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

Интересно, а кроме векторов можно ещё что-то хранить? Вложенные массивы... Выглядит неплохо, куда лучше, чем в том же Perl :)

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

Мапишь шареный сегмент во все процессы по одному и тому же адресу, создаёшь в нем арену аллокатора. И указатели на объекты, выделенные этим аллокатором будут одинаковые во всех процессах, и эти указатели можно будет хранить в этих объектах.

Вот оракл например мапит sga по одному и тому же адресу во все свои процессы. И это наверняка неспроста.

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

Интересно, а кроме векторов можно ещё что-то хранить?

Наверное, придется изгаляться.
Похоже это все же не средство языка, а отдельная библиотека.

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

QSharedMemory

+1, пользоваться этим действительно просто, однако наплевался когда оно не отпускало ресурс у крэшнутых программ, что-то там меня бесило помню

I-Love-Microsoft ★★★★★ ()

CL так делает в качестве нестандартной, но «все так делают» фичи. А Cloujre спеиально под это проектировали, даже в более обобщеном виде в виде транзакционй мдели памяти. А потом по образцу сделали библиотеку в CL:)

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

Вот я и думаю: если запускать в изолированном окружении, то все выделенные для выполнения ресурсы будут автоматически освобождены при завершении. Поможет ли в этом cgroups?

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

А потом по образцу сделали библиотеку в CL:)

Эта библиотека может связать clojure и, например, sbcl?

panzerito ()

shmget
shmat

Желательно, чтобы программа на языке «автомагически» умела чистить за собой созданные ею shared memory segment'ы при завершении дерева порождённых ею процессов.

Бери тогда mmap с MAP_ANONYMOUS | MAP_SHARED. munmap не нужно делать когда родитель всех процессов падает. По сути это наилучшее решение для тебя.

reprimand ★★★★★ ()
Последнее исправление: reprimand (всего исправлений: 3 )
Ответ на: комментарий от DRVTiny

Может проще для этого сделать мелкий демон, который будет работать параллельно с прогой и который не может упасть?

Всяко лучше привязки к конкретной ОС.

RazrFalcon ★★★★★ ()

безо всяких явных сериализаций/десериализаций

Без явных, но скрытых под капотом любой умеет. Вообще без сериализации - только языки без сборки мусора, очевидно.

Не использовать MQ, in memory NoSQL, ... etc, etc

Почему нет? Все эти извращения с shm_attach кончатся велосипедом на тему noSQL.

no-such-file ★★★★★ ()
Ответ на: комментарий от RazrFalcon

По мне, нет ничего лучше привязки к ОС. Я пишу не текстовый редактор или браузер ведь. Да и если уж говорить о специализированном софте - давайте расскажем разработчикам SolidWorks или AutoCAD'а о том, что они неправы и должны писать ещё и под Linux. В любой нормальной организации сделать виртуалку что под Windows, что под Linux - не проблема вообще ни разу. Сама по себе ОС (да и железо тоже) не имеет ни малейшего смысла без софта, который на ней работает. Так что да, в современных реалиях не только логичнее, но и правильнее оптимизировать софт под ОС и вообще под конкретные условия его применения - если конечно это не «популярный» софт на продажу миллионам благодарных хомячков.

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

ты можешь объяснить нормальными словами что ты хочешь получить в итоге? и желательно также не проигнорить мой прошлый пост

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

Хочу получить переменные, разделяемые между процессами и при этом ни коим образом, ни намёком, не связанные с такими понятиями, как «файлы», «очереди», «запросы», «десериализации». Просто переменные. Просто между процессами. Желательно не только тупо скаляры или векторы целых чисел.

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

ИМХО задача, вполне посильная разработчикам современных языков программирования.

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

ИМХО задача, вполне посильная разработчикам современных языков программирования.

Зачем это нужно разработчикам языков программирования, если эта задача решается посредством обычных библиотек?

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

Файлы/сокеты - это удобно, блокирующий вызов, автоматическая синхронизация. Очереди - это справедливо. Десериализация может потребоваться вдруг, когда окажется, что на одном тазике не тянет. А раз родитель один, то клиент-сервер - это не сложно, удобно, маштабируемо, велосипедов понаписано много на любой вкус с боку бантик.

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

ну и чем тебе мой ответ не устроил?

#define _BSD_SOURCE

#include <sys/mman.h>
#include <sys/wait.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <stdio.h>

typedef struct {
	int a;
	int b;
	size_t c;
} storage;

int main() {
	void *ptr = mmap(NULL, sizeof(storage), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
	if (ptr == MAP_FAILED) return EXIT_FAILURE;
	storage *yourdata = ptr;
	yourdata->a = 5;
	yourdata->b = 1005;
	yourdata->c = 999999;

	pid_t mypid = fork();
	if (mypid < 0) return 0;
	if (mypid > 0) {
		yourdata->a = 7;
		yourdata->b = 2007;
		yourdata->c = 888888;
		exit(0);
	}
	wait(NULL);
	printf("%d %d %zu\n", yourdata->a, yourdata->b, yourdata->c);
	return EXIT_SUCCESS;
}

Файлов, очередей, запросов нет. Что ты имеешь ввиду под десериализацией я хз. Переменные. Между процессами.

Желательно не только тупо скаляры или векторы целых чисел.

расскажи что ты хочешь еще кроме переменных. Твоя проблема в этом топике состоит в том, что ты не можешь или не хочешь объяснить ЧТО ТЕБЕ НУЖНО в итоге. Выкладывай всё, люди подтянутся и не будут вытягивать тебя по ниточке как следаки.

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

В коде выше родитель владеет тремя переменными, присваивает им значения. Создаем потомка. Модифицируем переменные. Выходим. Проверяем всё ли на месте.

На других ЯП не могу, сори.

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

Файлы/сокеты - это удобно, блокирующий вызов, автоматическая синхронизация. Очереди - это справедливо. Десериализация может потребоваться вдруг, когда окажется, что на одном тазике не тянет. А раз родитель один, то клиент-сервер - это не сложно, удобно, маштабируемо, велосипедов понаписано много на любой вкус с боку бантик.

Удобно, но ТС не объяснил задачу. Вдруг ему поллинг пачки дескрипторов и мудоханье с синхронизацией не нравится/не подходит.

reprimand ★★★★★ ()

Ох уж эти Java-макаки. То им кластерный синглтон аннотациями подавай, то IPC Shared Memory встроенный...

anonymous ()
Ответ на: комментарий от DRVTiny

давайте расскажем разработчикам SolidWorks или AutoCAD'а о том, что они неправы и должны писать ещё и под Linux.

Так что да, в современных реалиях не только логичнее, но и правильнее оптимизировать софт под ОС и вообще под конкретные условия его применения - если конечно это не «популярный» софт на продажу миллионам благодарных хомячков.

RazrFalcon ★★★★★ ()
Последнее исправление: RazrFalcon (всего исправлений: 1 )
Ответ на: комментарий от RazrFalcon

Почему у вас вопрос стоит таким образом, что она якобы там ожидалась? Я накидал ТС-у пример, подходящий под его критерии. А насчет (де)сериализации мне так и не объяснили.

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

Если что, во фразе «давайте расскажем разработчикам SolidWorks или AutoCAD'а о том, что они неправы и должны писать ещё и под Linux. » наверное как-то должен чувствоваться сарказм. Особенно если знать, сколько стоит тот же SolidWorks.

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

На других ЯП не могу, сори.

Так и вопрос был именно об этом.

О «других языках». О том, что в Си это всё возможно - итак понятно. Хотелось бы пример на чём-то менее низкоуровневом всё же.

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

В одном конкретном случае мне нужно хранить в shared memory древовидную структуру данных, периодически обновляемую главным процессом (родителем), а потомками только используемую для формирования ответов клиентам.

Преобразования в духе «encode/decode BJSON» меня, мягко говоря, не устраивают: я просто хочу читать из дочерних процессов структуру данных, со всеми ссылками и пр. Собственно, именно по причине её ссылочного характера хотелось бы, чтобы сам язык обеспечивал преобразования в духе «давай-ка я к твоему указателю прибавлю начало размещения страниц шареной памяти в твоём адресном пространстве». Т.е. мне кажется логичным описанный случай с Oracle'ом, когда там «абсолютно внезапно» шареные страницы у процессов располагались по одному и тому же адресу, так что спокойно можно было обходиться без всякой магии, но даже если вдруг после форка именно шареная часть представления виртуального адресного пространства процесса куда-то переезжает - хотелось бы, чтобы язык сам обеспечивал все подстройки адресов.

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

Я о том, что вы предлагаете оптимизировать софт под конкретную ОС (фактически вендорлок предлагаете), а затем сами же соглашатель с тем, что популярный софт должен быть доступен на всех ОС.

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

В одном конкретном случае мне нужно хранить в shared memory древовидную структуру данных, периодически обновляемую главным процессом (родителем), а потомками только используемую для формирования ответов клиентам.

Храните эту структуру данных в файле, а место, где файл будет лежать смонтируйте в ramdisk. Простого, готового, прям сдесь и сейчас нет. Либо есть, но очень спечифическое.

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

О «других языках». О том, что в Си это всё возможно - итак понятно. Хотелось бы пример на чём-то менее низкоуровневом всё же.

Попросите у кого-то написать обёртку/либу для вашего ЯП.

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

Так вы ещё и ТЗ составлять не умеете. Написали бы это в шапке - половина вопросов сразу бы отпала.

Составить грамотное ТЗ - целое исскусство. Это чуть ли не половину задачи выполнить.

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

Вот я и думаю

Вот я и думаю, какого черта ты лезешь в IPC, если не знаешь даже о pthread_mutexattr_setrobust. В принципе, это хорошо вписывается в «портрет типичного прогромизда на КьюТи»

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

Именно. ТС ищет язык, в котором легко реализуется IPC. То есть беспроблемный доступ к одним и тем же данным из разных потоков/процессов.

Вы же, предлагаете ему язык, в котором эта задача недостижима даже в пределах одного потока.

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

Храните эту структуру данных в файле, а место, где файл будет лежать смонтируйте в ramdisk

Ты сейчас описал POSIX shared memory: man shm_open.

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