Системный вызов read для shm, pipe

3. Есть ли операционные системы, где системный вызов read находится в пространстве пользователя?

не думаю, ведь в любом случае read читает из одной области памяти и пишет в другую, нужен доступ в ядро или области памяти должны находится в одном контектсте, как это делается в shared memory.

Каким образом происходит чтение, например, массива из shared memory?

for (i = 0; i < sizeof(array); i++) {dst[i] = src[i]};

ядро заранее заботится, чтобы адреса были видны из обоих процессов.

как это делается в системном вызове read не знаю, но суть все равно в том, что данные, лежат в одной области памяти и их нужно скопировать в другую область памяти, но read конечно сложнее, так как это не shared memory.

read в ядре будет сильно зависеть от того, что вы читаете, если файл с диска, то будет доступ к диску, если стандартный поток, то будет копироваться память из одного контекста в другой.

Почему тогда пайпы реализованы не через shm?

ls | grep a

если хотите знать, как устроены read/write стандарнтых потоков Linux, то смотрите в драйвер /dev/pts/[0-9]

Почему тогда пайпы реализованы не через shm?

где реализованы?

если вы читаете с диска, то реализация read/write будет в ext4, если чиатете /proc, то реализация read/write будет в драйвере proc и т.п.

может так и устроено, при создании pipe не обязательно обращаться в ядро, тогда библиотека сама должна отслеживать, куда идет вызов read/write и если вызов идет к pipe, то достаточно использовать стандартную библиотеку, однако в таком случае, если вы сделаете вызовы read/write без помощи библиотеки, то есть непосредственно в ядро (это можно сделать с помощью ассемблерных вставок) то такой вызов не увенчается успехом.

Почему тогда пайпы реализованы не через shm?

если это сделано не через shm, значит это сделано для унификации интерфесов, если через shm, значит ассемблерной вставкой сделать вызов read/write к pipe не получится.

А когда именно им «сохранять», «использовать» и «удалять» этот байт они конечно же поймут, вызвав generic_guess(NULL) из libastral.so. Без лишнего дерганья ядра.

2. Будет ли сказываться на работе системы нагруженный IO при работе с пайпами? Копирование данных на флешку, например, приводит к сильным зависаниям системы (нагрузка процессора при этом не больше нескольких процентов).

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

Область занятая - используем и удаляем, пустая - записываем. Для начала что есть shm, а точнее в каком виде хранятся данные на примере массива?

Мда.

в каком виде хранятся данные на примере массива?

в виде элементов этого массива :)

бласть занятая - используем и удаляем, пустая - записываем.

это делается на основе мьютексов или семафоров

1. Тогда какие типы данных можно там хранить? Всё, что есть в C?
2. Почему dbus не выбрал способ передачи данных именно через shm? Для сообщений: программа А хочет отправить сообщение, вызывает функцию из libdbus, в качестве параметра указываем получателя и сообщение -> создается в shm переменная-строка с сообщением, имя переменной отправляется на шину, с нее к приложению-получателю, она обрабатывает строку и подчищает за собой (для халявщиков можно ввести глобальное ограничение: сообщения хранятся только 5 минут, например). Этот способ можно приплести ко всем возможностям dbus'а в качестве обмена информацией. Как идея?

Тогда какие типы данных можно там хранить? Всё, что есть в C?

все, что можно хранить в памяти, так как shm это и есть обычная память.

2 не работал с libdbus, не могу оценить.

Идея отличная — срочно кодируй, а то забудешь.

На доске, полностью исписанной циферками, я в скором времени собираюсь стереть участок и записать другие циферки. Как постороннему наблюдателю, периодически отворачивающемуся от доски, понять, что это еще не / уже произошло? Как мне понять, что он уже прочитал те циферки и можно писать новые?

Почему dbus не выбрал

Хз. Возможно, слишком много возни, возможно, соображения безопасности. Скорее всего всё вместе.

Как идея?

Так и делают, см. http://nanomsg.org/documentation-zeromq.html (ищи «shared memory» в тексте)

Как мне понять, что он уже прочитал те циферки и можно писать новые?

Так же как и с обычной памятью: держать структуру данных для этого. Я не удивлюсь если кто-то уже придумал как с этим работать без блокировок (а может и нет, гугли lock-free shared memory). Как я писал выше, ipc через shared memory вполне себе существует. Есть даже круче трава, ipc через remote DMA.

man mit-shm. дибилиас в этом не нуждается, данных мало передаётся.

Не понял, честно говоря, вопроса. Недосып-с.

Оффотоп: писали подсистему вывода информации на дисплей. Идея, вкратце, такая: несколько демонов-пользователей перехватывают информацию от владельцев сервисов и выводят её на участки экрана.

Всё было нарисовано, конечно, красиво, но я реально умучился с реализацией этого чуда-юда.

кто-то уже придумал как с этим работать без блокировок

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

Remote dma это такой же чит как shm через send/recv?

либо, либо

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

Remote dma это такой же чит как shm через send/recv?

Что есть shm через send/recv? RDMA: https://en.wikipedia.org/wiki/Remote_direct_memory_access

1. Стоит ли считать работу связанных программ через stdin/stdout недостатком? Взять те же GNU-utils, например. При одновременном использовании.
2. Есть ли варианты без перекомпиляции заставить эти утилиты работать через nanomsg?
3. А с перекомпиляцией? Подойдет ли подменяемая библиотека-прослойка?

Как идея?

Пока в Вилларибо передадут туда-сюда все, что необходимо для безопасной организации передачи через shm, в Виллабаджо уже и сообщение передадут, и ответ получат. Через обычный нынче немодный dbus.

Стоит ли считать работу связанных программ через stdin/stdout недостатком?

У тебя какие-то филосовские вопросы. Ты уже убедился в том что у тебя пайпы это узкое место?