Разработка концептуально новой ОС

Домены - это одно. Тут понятно. Сообщения им регулируются. Но междоменные вызовы !!!

Цитата rcz, 12.09.03, 18:32:57

Предполагал, что все объекты имеют разные адресные пространства. А чтоб их переключить, нужно в ядро.

Насколько я понимаю, в KeyKOS так и есть. Сообщения посылаются либо объекту в ядре, либо в другой домен, объект которого в другом адресном пространстве. Но если мы допустим посылку объекту в том же домене...

Цитата rcz, 12.09.03, 18:37:44

Домены - это одно. Тут понятно. Сообщения им регулируются. Но междоменные вызовы !!!

Тогда само собой, syscall для посылки в др. домен.

Цитата

Тогда само собой, syscall для посылки в др. домен.

Вот. А посылку таких сообщения я и пытаюсь описать!!!. Это будет уже через ядро, очередь по приоритетам.

Сообщение отредактировано: rcz - 12.09.03, 14:43

Т.е. Мне бы хотелось, чтоб это было в ядре. А дальше (Это же микроядерное ядро и ООП-система) можно всякое надстраивать.

Сообщение отредактировано: rcz - 12.09.03, 14:49

Цитата rcz, 12.09.03, 18:42:56

Вот. А посылку таких сообщения я и пытаюсь описать!!!. Это будет уже через ядро, очередь по приоритетам.

Мою идею о том, как это м. работать без очередей со стороны ядра, я уже описал.

Теперь давай поговорим о твоей.
Что ты предлагаешь?
1. Заставить ядро ставить сообщения в очередь?
2. Выдавать домену пришедвие сообщения по одному, вроде GetMessage(...), или же на каждое сообщение автоматически создавать тред?

Цитата rcz, 12.09.03, 18:48:14

Т.е. Мне бы хотелось, чтоб это было в ядре. А дальше (Это же микроядерное ядро) можно всякое надстраивать.

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

Вопрос, конечно, сложный. С наскока не решается...

Кстати, я не понял, что же мы решили по поводу сайта?
Надо бы хост подыскивать...
Я тут ссылок нарыл в инете:
http://www.hostobzor.ru
http://www.hostsearch.ru/
http://forum.ru-board.com/forums.cgi?forum=11

Про приоритеты писал.
0 - 16 - прерывание и главный планировщик
Далее Пользовательские. (можно от 17 до 0xffffffff). Хотя надо согласовать.

Цитата

1. Заставить ядро ставить сообщения в очередь?
2. Выдавать домену пришедвие сообщения по одному, вроде GetMessage(...), или же на каждое сообщение автоматически создавать тред?

Ставить в очереди. При обработке прыгать на обработчик (method, его адрес можно получить) можно отдельным тредом.

GetMessage что-то использовать не хочется. Хотя как вариант.

Цитата rcz, 12.09.03, 19:00:38

Про приоритеты писал.
0 - 16 - прерывание и главный планировщик
Далее Пользовательские. (можно от 17 до 0xffffffff). Хотя надо согласовать.

Ставить в очереди. При обработке прыгать на обработчик (method, его адрес можно получить) можно отдельным тредом.

GetMessage что-то использовать не хочется. Хотя как вариант.

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

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

GetMessage - можно и так, но можно и что-то вроде сигналов в unix

Цитата

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

Это для того, чтобы сами драйвера были как приложения - объекты. И думаю тут сообщения типа как для Bottom Halves в Linux

Цитата

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

Без этого будет хаос или что-то вроде Round Robinа. Можно будет их разделить на разные классы (сообщения  драйверам, другим пользовательским процессам, интерфейс и т.п.). Из пользовательских приоритетов можно все разбить на диапазоны, далее пользователь сам определяет приоритет сообщения. Если бояться, что кто-то будет занимать самые приоритетные, тут надо вспомнить существование Real Time приоритета в Windах(оно ест, занимает все ресурсы, но им не пользуются)

Более того - получится хороший алгоритм планирования по приоритетам.

2rcz&Vilmor
По поводу сообщений, наверное, придется провести голосование, но для этого нужно каждому четко сформулировать мнение.

Выскажу свое.
1) Реализовать RunMessage в исходном виде (соответствует CALL+RETURN, но без FORK).
2) Реализовать очередь сообщений для Post/SendMessage, через GetMessage(), причем очередь хранится в пространстве получателя.

В общем, после раздумий, я пришел к исходному варианту.
Аргументы следующие.
1) Реализация FORK_message очень ресурсоемка - на каждое сообщение нужно создавать поток (т.е. стек в N кб), что смешно, если само сообщение 10 байт. Пул - некрасиво.
2) Корректную поддержку FORK_message сделать сложнее, чем очередь. Например, если функция обработки содержит бесконечный цикл (ошибка программиста), а поток сообщений интенсивен? Система "утонет" в тредах.
3) Особой пользы от FORK_message нет. Если нужно, чтобы программа продолжала работу после отправки сообщения - просто создавать заранее доп. рабочий поток.
4) Если приложение хочет упорядочить сообщения по собственным приоритетам, оно может их просто считать и поместить в свою внутреннюю очередь, где уже не спеша обрабатывать.

Цитата

Выскажу свое.
1) Реализовать RunMessage в исходном виде (соответствует CALL+RETURN, но без FORK).
2) Реализовать очередь сообщений для Post/SendMessage, через GetMessage(), причем очередь хранится в пространстве получателя.

Да, в принципе можно хранить очередь в адресном пространстве получателя, но...
Я пытаюсь построить механизм планирования на сообщениях(нужно же реализовать многозадачность), но если очередь в разных адресных пространствах, могут быть проблеммы.
Поэтому предлагаю такую схему. Очередь сообщений на уровне системы (RING1-2). Содержит Key отправителя и получателя,Код Сообщения, а так же указатель на данные сообщения в адресном пространстве получателя. При обработке сообщения этот буфер копируется получателю. Освобождением занимаются сами получатель и отправитель.

Цитата

3) Особой пользы от FORK_message нет. Если нужно, чтобы программа продолжала работу после отправки сообщения - просто создавать заранее доп. рабочий поток.

Асинхронность с очередями реализуется просто. А нагружать прикладного программиста лишними деталями не стоит.

Цитата

4) Если приложение хочет упорядочить сообщения по собственным приоритетам, оно может их просто считать и поместить в свою внутреннюю очередь, где уже не спеша обрабатывать.

Тут все проблема не одного конкретного приложения, а всей системы. Если много приложений отправило одному процессу одновременно несколько сообщений. Как тут быть?

Цитата rcz, 12.09.03, 23:41:32

Да, в принципе можно хранить очередь в адресном пространстве получателя, но...
Я пытаюсь построить механизм планирования на сообщениях(нужно же реализовать многозадачность), но если очередь в разных адресных пространствах, могут быть проблеммы.
Поэтому предлагаю такую схему. Очередь сообщений на уровне системы (RING1-2). Содержит Key отправителя и получателя,Код Сообщения, а так же указатель на данные сообщения в адресном пространстве получателя. При обработке сообщения этот буфер копируется получателю. Освобождением занимаются сами получатель и отправитель.

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

Цитата

Асинхронность с очередями реализуется просто. А нагружать прикладного программиста лишними деталями не стоит.

Интерпретирую это как согласие: FORK_messages убираем.

Цитата

Тут все проблема не одного конкретного приложения, а всей системы. Если много приложений отправило одному процессу одновременно несколько сообщений. Как тут быть?

А чем не нравится предложение: пусть приложение их считает без обработки и само рассортирует по внутренним очередям. Это не будет нагружать прикладного программиста, потому что мало кому нужно.
В PostMessage все равно действительно срочные события передаваться не должны - для этого остается RunMessage, которое всегда обрабатывается немедленно.

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

Сообщение отредактировано: vilmor - 13.09.03, 07:58