любая ос на наших железках это жесть. в любой цпм или юзиксе или издос или дна и прочих, любая прога может нагадить в систему и грохнуть её. и что теперь? учитесь нормально програмить, чтобы ваша прога не гадила.
любая ос на наших железках это жесть. в любой цпм или юзиксе или издос или дна и прочих, любая прога может нагадить в систему и грохнуть её. и что теперь? учитесь нормально програмить, чтобы ваша прога не гадила.
NovaStorm, ага понял, это относительно к микрофеням.
Sayman, конечно можно писать нормально, и всё будет прекрасно работать, речь шла просто о том, что городить неоправданные концепты, не подходящие для нашего железа не стоит. Передача сообщений сожрёт как лишнюю память для реализации и буферов, так и время на переключение контекстов, а преимуществ практически не даст.
Ну и если уж зашла об этом речь, имхо нужен монолит, возможно что и с модулями, но загружаться они уж точно должны внешним кодом.
про какие сообщения идёт речь? тут уже была какая то тема про якобы ос с почтовыми ящиками и горой сообщений. про это чтоли речь? если же смотреть в сторону мпм или юзи то никаких сообщений нет, есть сигналы. системы при этом многопользовательские/многозадачные. работа мпм на z80 давно известна, исходники есть. аналогично и про юзи. велосипед изобретён, в нашем случае, больше 20 лет назад.
>про какие сообщения идёт речь?
Про эти:
http://ru.wikipedia.org/wiki/Обмен_сообщениями
подозреваю, что текст по ссылке или неверный перевод или вольная трактовка.
читаем лучше это
http://ru.wikipedia.org/wiki/%D1%E8%...E0%EB%FB_(UNIX)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Сигналы тут почти и не причём, с помощью сообщений обмениваются данными, используется для IPC и RPC. Message passing оно на буржуйском.
значит, если быть немного чуть внимательнее, то можно заметить, что Message passing, а точнее Message Passing Interface (MPI) не является неким стандартом дефакто для целого ряда систем, в том числе и для винды и позикса (тот же юникс). каждая система сама идёт по своему пути и использует свою систему "сообщений" везде они именуются по разному но смысл примерно у всех одинаков. будем называть вещи своими именами - для позикса (юникса) это именно сигналы, которые являются частью взаимодействия между процессами (IPC, inter-process communication). если внимательно поизучать исходники той же фриБСД, то кроме сигналов есть ещё сокеты. в винде же есть свой интерфейс - WMI который чуть более широк в применении, чем сигналы и сокеты у юникса. сам же MPI является сторонней разработкой и например для винды существует отдельная реализация.
более детально об этом тут
касательно применения в спекрумах, то невижу никаких особых проблем в реализации и применении любого из способов. о5-таки - uzix прекрасно работает с сигналами, т.е. часть интерфейса IPC реализована. другое дело что не навсех клонах такое реализуемо. например, на пнях и других 128х моделях видимо ждёт облом. а вот такие модели как профи, атм, недоэва, феникс, спринтер и им подобные, думаю без проблем потянут такое. особенно если турбированные модели.
Последний раз редактировалось Sayman; 01.01.2012 в 13:28.
>для позикса (юникса) это именно сигналы
Передавать данные через сигналы конечно можно, но не нужно =)
>не навсех клонах такое реализуемо
Почему же? С сигналами как раз проблем я не вижу.
Все прекрасно будет и без защиты памяти работать. Защита памяти это лишь дополнительная плюшка, облегчающая жизнь программисту, не давая ему заморачиваться на дополнительные примудрости в коде.
Для не веруюших -- Linux работает и на процах без аппаратного MMU. Кто не верит, может почитать исходники. Да, сегодня проц без MMU это архаизм, но бывают моменты, когда оно и не надо вовсе.
В принципе, на клонах с объемом RAM > 128k механизм переключения банков RAM как раз и является тем самым MMU, реализованным вне CPU.
Вижу я все это так:
Нужно уменьшить гранулярность при переключении и отображении банков с 16/64k до 4k. И отображать по 4k в пространство проца. Кажому процессу будет принадлежать свой набор страниц по 4k, и у других процессов не будет доступа к чужой памяти. Чем вам не MMU? Да конечно, это вариант не делит области памяти по уровням доступа и типу содержимого ( код,данные, стек). Но свою работу по изоляции процессов он делает. Или я не прав?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)