Предлагаю улучшить работу IPC за счёт реализации IPC-сигналов. Сигнал - это 32(64)-битное число передаваемое от одного процесса к другому. При получении сигнала, ОС останавливает выполнение процесса-приёмника и передаёт управление обработчику сигнала, который по умолчанию определяет операционная система. Программа может установить собственный обработчик сигналов. Что это даёт? Приведу несколько примеров:
1) Оконный сервер. Программа определяет буфер окна (что-то наподобие canvas'а), рисует в нём, потом посылает сигнал обновления своего окна. Окно изменено. Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная. Через сигналы же, всё будет куда быстрее .
2) Многопоточная программа. Например, файловый менеджер. Человек копирует файлы. В этот момент другой поток отрисовывает основное окно (которое при этом неактивно). Как только поток, копирующий файлы, завершает работу он даёт сигнал основному потоку - тот разблокирвывает окно и работа с ФМ-ом продолжается.
3) Консоль. При запуске консольной программы, оболочка создаёт блок расшаренной памяти и передаёт сведения о нём консольному приложению. Утилита командной строки делает свою работу, заливает в буфер различные данные и посылает сигнал оболочке. Оболочка этот буфер обрабатывает, изменяет если надо, выводит на экран то, что нужно и так далее. Опять же скорость может быть больше, чем при работе через 60-ую функцию.
4) Завершение работы. Перед выключением ОС может оповестить каким-то стандартным сигналом все процессы (вместо того, чтобы тупо их убить) и даёт им возможность сохранить изменившиеся данные.
Основные преимущества - не нужно определять буфер памяти, не нужно к этому буферу обращаться (что даёт большой прирост скорости), упрощение работы с IPC.
Эта идея требует до- и проработки, поэтому я предлагаю обсудить это.
Улучшаем IPC
-
ушёл...
Хочу такие FPSNasarus wrote:1) Оконный сервер. Программа определяет буфер окна (что-то наподобие canvas'а), рисует в нём, потом посылает сигнал обновления своего окна. Окно изменено. Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная. Через сигналы же, всё будет куда быстрее .
Статья по теме на английском, ну или её русскоязычный вариант, кому как удобнее.
Из перечисленного там у нас есть обмен сообщениями и разделяемая память, сокеты пока только в качестве планов на будущее в сетевой ветке ядра http://wiki.kolibrios.org/wiki/New_stack.
Я за улучшение IPC.
Однако пока столкнулся только с одной проблемой: Как отправитель может получить PID/TID получателя? (Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )
Цитата: "Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная."
"Здравый смысл" мне подсказывает, что копирование скажем 16 байт потребует порядка 4*4 обращений к памяти. Если даже всё будет совсем плохо, то это всё равно порядка 200 - 300 тактов: существенно меньше издержек двойного переключения контекста. Обновление экрана потребует на пару порядков больше тактов процессора. Где я ошибаюсь?
Однако пока столкнулся только с одной проблемой: Как отправитель может получить PID/TID получателя? (Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )
Цитата: "Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная."
"Здравый смысл" мне подсказывает, что копирование скажем 16 байт потребует порядка 4*4 обращений к памяти. Если даже всё будет совсем плохо, то это всё равно порядка 200 - 300 тактов: существенно меньше издержек двойного переключения контекста. Обновление экрана потребует на пару порядков больше тактов процессора. Где я ошибаюсь?
Вроде как этот метод самый надежный.FireWall wrote:Я за улучшение IPC.
Однако пока столкнулся только с одной проблемой: Как отправитель может получить PID/TID получателя? (Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )
Вызов, например, процедуры отправки IPC-сообщения помимо кучи проверок содержимого слота, переполнения буфера, занятости (блокировки) буфера, ещё и выделяет память ядра и освобождает её, и "Здравый смысл" мне подсказывает, что одна посылка такого сообщения обходится куда больше, чем в 200 - 300 тактов.FireWall wrote: Цитата: "Да, конечно это можно реализовать через нынешние IPC функции, но если программа будет делать тысячи таких обновлений в минуту (например, видеоигра или медиаплеер) скорость будет очень медленная."
"Здравый смысл" мне подсказывает, что копирование скажем 16 байт потребует порядка 4*4 обращений к памяти. Если даже всё будет совсем плохо, то это всё равно порядка 200 - 300 тактов: существенно меньше издержек двойного переключения контекста. Обновление экрана потребует на пару порядков больше тактов процессора. Где я ошибаюсь?
ушёл...
Файлы забылAsper wrote: Из перечисленного там у нас есть обмен сообщениями и разделяемая память, сокеты пока только в качестве планов на будущее в сетевой ветке ядра http://wiki.kolibrios.org/wiki/New_stack.
ушёл...
Почему же топорное? IBM со своей z/OS не стала бы использовать разделяемую память, если бы это было так - в IBM не последние дураки работают. К тому же разделяемая память на сегодня обеспечивает производительность минимум на порядок превышающий текущую реализацию IPC.FireWall wrote:(Я пока это решаю посредством именованной разделяемой памяти - но это топорное решение ... )
Так на всякий случай :
Топорным решением я считаю использование именной разделяемой памяти для получения (только!) одного числа - PID/TID процесса - держателя буфера IPC.
Цитата: "Вызов, например, процедуры отправки IPC-сообщения помимо кучи проверок содержимого слота, переполнения буфера, занятости (блокировки) буфера, ещё и выделяет память ядра и освобождает её"
Тогда надо также подумать, как усовершенствовать уже имеющийся механизм отправки сообщений:
- проектируемое, для очень маленьких "сообщений - сигналов";
- усовершенствованное имеющееся, для средних сообщений с буфером, не пересекающим "межстраничный барьер" (именной доступ + непосредственное копирование из "буфера" отправителя в "буфер" получателя);
- именная разделяемая память, для больших данных (> одной страницы).
Топорным решением я считаю использование именной разделяемой памяти для получения (только!) одного числа - PID/TID процесса - держателя буфера IPC.
Цитата: "Вызов, например, процедуры отправки IPC-сообщения помимо кучи проверок содержимого слота, переполнения буфера, занятости (блокировки) буфера, ещё и выделяет память ядра и освобождает её"
Тогда надо также подумать, как усовершенствовать уже имеющийся механизм отправки сообщений:
- проектируемое, для очень маленьких "сообщений - сигналов";
- усовершенствованное имеющееся, для средних сообщений с буфером, не пересекающим "межстраничный барьер" (именной доступ + непосредственное копирование из "буфера" отправителя в "буфер" получателя);
- именная разделяемая память, для больших данных (> одной страницы).
Who is online
Users browsing this forum: No registered users and 35 guests