Улучшаем IPC

Thu Oct 28, 2010 2:34 pm

Предлагаю улучшить работу IPC за счёт реализации IPC-сигналов. Сигнал - это 32(64)-битное число передаваемое от одного процесса к другому. При получении сигнала, ОС останавливает выполнение процесса-приёмника и передаёт управление обработчику сигнала, который по умолчанию определяет операционная система. Программа может установить собственный обработчик сигналов. Что это даёт? Приведу несколько примеров:
1) Оконный сервер. Программа определяет буфер окна (что-то наподобие canvas'а), рисует в нём, потом посылает сигнал обновления своего окна. Окно изменено. Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная. Через сигналы же, всё будет куда быстрее

.
2) Многопоточная программа. Например, файловый менеджер. Человек копирует файлы. В этот момент другой поток отрисовывает основное окно (которое при этом неактивно). Как только поток, копирующий файлы, завершает работу он даёт сигнал основному потоку - тот разблокирвывает окно и работа с ФМ-ом продолжается.
3) Консоль. При запуске консольной программы, оболочка создаёт блок расшаренной памяти и передаёт сведения о нём консольному приложению. Утилита командной строки делает свою работу, заливает в буфер различные данные и посылает сигнал оболочке. Оболочка этот буфер обрабатывает, изменяет если надо, выводит на экран то, что нужно и так далее. Опять же скорость может быть больше, чем при работе через 60-ую функцию.
4) Завершение работы. Перед выключением ОС может оповестить каким-то стандартным сигналом все процессы (вместо того, чтобы тупо их убить) и даёт им возможность сохранить изменившиеся данные.
Основные преимущества - не нужно определять буфер памяти, не нужно к этому буферу обращаться (что даёт большой прирост скорости), упрощение работы с IPC.
Эта идея требует до- и проработки, поэтому я предлагаю обсудить это.

Thu Oct 28, 2010 3:24 pm

Nasarus wrote:1) Оконный сервер. Программа определяет буфер окна (что-то наподобие canvas'а), рисует в нём, потом посылает сигнал обновления своего окна. Окно изменено. Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная. Через сигналы же, всё будет куда быстрее .

Хочу такие FPS

Статья по теме на английском, ну или её русскоязычный вариант, кому как удобнее.
Из перечисленного там у нас есть обмен сообщениями и разделяемая память, сокеты пока только в качестве планов на будущее в сетевой ветке ядра http://wiki.kolibrios.org/wiki/New_stack.

Thu Oct 28, 2010 4:31 pm

Я за улучшение IPC.

Однако пока столкнулся только с одной проблемой: Как отправитель может получить PID/TID получателя? (Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )

Цитата: "Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная."

"Здравый смысл" мне подсказывает, что копирование скажем 16 байт потребует порядка 4*4 обращений к памяти. Если даже всё будет совсем плохо, то это всё равно порядка 200 - 300 тактов: существенно меньше издержек двойного переключения контекста. Обновление экрана потребует на пару порядков больше тактов процессора. Где я ошибаюсь?

Thu Oct 28, 2010 7:20 pm

FireWall wrote:Я за улучшение IPC.

Однако пока столкнулся только с одной проблемой: Как отправитель может получить PID/TID получателя? (Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )

Вроде как этот метод самый надежный.

FireWall wrote: Цитата: "Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная."

"Здравый смысл" мне подсказывает, что копирование скажем 16 байт потребует порядка 4*4 обращений к памяти. Если даже всё будет совсем плохо, то это всё равно порядка 200 - 300 тактов: существенно меньше издержек двойного переключения контекста. Обновление экрана потребует на пару порядков больше тактов процессора. Где я ошибаюсь?

Вызов, например, процедуры отправки IPC-сообщения помимо кучи проверок содержимого слота, переполнения буфера, занятости (блокировки) буфера, ещё и выделяет память ядра и освобождает её, и "Здравый смысл" мне подсказывает, что одна посылка такого сообщения обходится куда больше, чем в 200 - 300 тактов.

Thu Oct 28, 2010 7:22 pm

Asper wrote: Из перечисленного там у нас есть обмен сообщениями и разделяемая память, сокеты пока только в качестве планов на будущее в сетевой ветке ядра http://wiki.kolibrios.org/wiki/New_stack.

Файлы забыл

Thu Oct 28, 2010 8:23 pm

FireWall wrote:(Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )

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

Sat Oct 30, 2010 2:54 pm

Так на всякий случай :

Топорным решением я считаю использование именной разделяемой памяти для получения (только!) одного числа - PID/TID процесса - держателя буфера IPC.

Цитата: "Вызов, например, процедуры отправки IPC-сообщения помимо кучи проверок содержимого слота, переполнения буфера, занятости (блокировки) буфера, ещё и выделяет память ядра и освобождает её"

Тогда надо также подумать, как усовершенствовать уже имеющийся механизм отправки сообщений:
- проектируемое, для очень маленьких "сообщений - сигналов";
- усовершенствованное имеющееся, для средних сообщений с буфером, не пересекающим "межстраничный барьер" (именной доступ + непосредственное копирование из "буфера" отправителя в "буфер" получателя);
- именная разделяемая память, для больших данных (> одной страницы).

Улучшаем IPC

Who is online