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

Си, один процесс, нити.

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

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

Go жи

но можешь вынимать контракты на убийство...
.

подозрительные у вас ассоциации :)
.
. Python вроде как подходит.
. https://docs.python.org/2/library/multiprocessing.html
. См. раздел Shared Memory.
.

Erlang ?

QSharedMemory

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

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

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

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

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

QSharedMemory

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

Да, при падении проги останется висеть... Но тут смена языка не поможет.

Java

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

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

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

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

Удваиваю. И ETS с флажком public.

shmget
shmat

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

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

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

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

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

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

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

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

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

Вы сами себе противоречите.

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

Haskell
http://eax.me/haskell-parallel/

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

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

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

Вы сами себе противоречите.

Где, каким образом противоречу???

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

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

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

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

#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;
}

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

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

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

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

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

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

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

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

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

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

И где у вас сериализцая и синхронизация?

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

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

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

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

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

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

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

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

без плясок с бубном
сишка

ну вы поняли

Я и не пишу популярный софт :) У меня он сугубо под конкретную задачу работодателя.

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

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

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

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

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

ну вы поняли

Ты знаешь что присваивать человеку чужие слова - очень плохая идея? Нет? Ну ладно.

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

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

Какие ещё чужие слова? Это были цитаты.

Я не говорил слов «без плясок с бубном» в этом треде. Это слова ТС-а.

Вот я и думаю

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

А ТС что, «прогромизд» на Qt?

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

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

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

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