Тут надо иметь в виду что система совершенно другая и проектировать надо тоже по другому.
AVK>Рендерер переключать в процессе работы смысла не имеет,
Да? А какже всякие WinAMP'ы со своими скинами? AVK>ак что его лучше вобще динамически не грузить,
Не факт. AVK>а предоставлять ввиде обычной библиотеки на MSIL.
Ну от этого по поределению никуда не деться. AVK>Правда для таких фокусов нужно либо предоставлять мощную метаинформацию управления системной компиляцей MSIL, либо создавать предварительно отдельный процесс-стартер, который будет осуществлять управление компиляцией приложения основного.
Допустим у нас мегапопулярный проигрыватель музыки к которому фанаты понаписали тысячи скинов и что все эти скины сразу вкомпиливать в ядро? А если во время работы плеера пользователь скачал с инета новый скин и хочет его посмотреть? Что перезагружать программу?
Вобщем от динамической загрузки тут никуда не денешся.
В данном случае я бы спроектировал так:
Ядро приложения (model) предоставляет рендеру (view) два канала (controller) первый работает по инициативе приложения (тут эта композиция кончилась какую играть дальше?..) второй работает по инициативе рендера (начни проигрывать трек номер 123...).
Все получается довольно гибко и полностью изолировано.
Кстати чем больше я по этому поводу думаю тем это подход мне нравится все больше. Тут просто нужно понять что общение между процессами почти бесплатно и начать думать в терминах процессов.
Здравствуйте, WolfHound, Вы писали:
AVK>>Рендерер переключать в процессе работы смысла не имеет, WH>Да? А какже всякие WinAMP'ы со своими скинами?
Скины и рендерер это мягко говоря, разные вещи. Рендерер это некоторая сущность, которая непосредственно осуществляет операцию отрисовки. Ну вроде как в Авалоне сначала был рендерер поверх GDI, а теперь поверх DirectX.
А скинам а-ля винамп динамический код не нужен, там просто набор картинок и декларативный дескриптор.
WH>Кстати чем больше я по этому поводу думаю тем это подход мне нравится все больше. Тут просто нужно понять что общение между процессами почти бесплатно и начать думать в терминах процессов.
Опять же все зависит от архитектуры приложения. Боюсь портирование с классических ОС кода крайне затруднено. Однако вполне возможны специализированные решения. Тот же рендерер, как тут неоднократно предлагалось, можно сделать конвеерным, тогда передача данных в чужой SIP с программной точки зрения будет очень простым.
Но, опять же, все это нуждается в очень тщательном обдумывании. Идея того класса, где ответ дать очень сложно.
... << RSDN@Home 1.2.0 alpha rev. 629 on Windows XP 5.1.2600.131072>>
Здравствуйте, srggal, Вы писали:
S>Ещё, как следствие, в управляемой ОС должны быть каие-нить "делегаты" на interrupt-handlers
Как ни странно, что-то отдалённо похожее по смыслу как раз сейчас в NT и есть. Называется deferred procedure call (DPC). Грубо говоря: приходит прерывание, обработчик (ISR) имеет минимум функционала (это требование) и для основной обработки данных ставит вызов отложенной процедуры в очередь. Планировщик потом запускает эту DPC. В общем-то технически не важно, будет ли DPC управляемым кодом или нет (естесственно, при соответствующей поддержке со стороны диспетчера).
Ещё такой интересный момент — в NT переключение тредов происходит по таймеру (причём програмно — ради скорости). Из-за довольно большого периода таймера сложно получить систему реального времени, любой тред может прерваться в любой момент на x*15мс и получит процессор обратно когда поезд уже уйдёт. Если уменьшать периодичность таймера — а обработка прерывания не такая уж и бесплатная операция — получим траты времени впустую только на переходы в ядро и обратно, то есть производительность в целом упадёт. Если же убрать переходы между кольцами защиты и сам таймер — можно програмно получить гарантированное время отклика. Но только в управляемом коде, в опасном будет как в Win 3.11, когда кто угодно может порушить систему
Самое интересное, что "лишние тормозные проверки" могут быть на самом деле бесплатны. Ядро процессора намного быстрее чем шина памяти и часто конвеер простаивает в ожидании данных.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
AVK>Singularity uses SIPs to encapsulate. Every device driver, system process, application, and
AVK>extension runs in its own SIP and communicates over channels that provide limited and
AVK>appropriate functionality. If code in a SIP fails, it terminates, which allows the system to reclaim
AVK>resources and notify communication partners.
Напоминает Эрланг с нодами, everything is a process, общение между процессами с помощью asynchronous message passing, нотификацией системой об умирании нодов. В общем, интересно будет увидеть, во что это выльется
VD>По предварительным данным, Vista — это следующая версия ОС семейства NT. Она не содержит в себе ни строчки управляемого кода. 100% кода Vista является неуправляемым и не безопасным.
VD>По подтвержденным данным, Singularity содержит 98% управляемого управляемого кода причем более 70% кода является полностью безопасным упаравляемым кодом.
Похоже, все разговоры вокруг Longhorn/Vista как о cистеме следующего поколения были ни чем
имым, кроме как коммерческим трюком. Помнится, похожие разговоры велись вокруг Win95, но в той ситуации мы получили операционку, на говолу превышающую Win3.1. Сейчас же имеем примерно такую картину:
1) ядро — доработанная Win2000/XP/2003;
2) режим пользователя — господство Win32 API;
3) отдельные фичи — поддержка доступа посредством .NET.
На мой взгляд, при таких раскладах .NET видится мне как продолжение и замена COM. Ведь к некоторым фичам Win2000/XP/2003 можно обратиться только через COM. Теперь роль COM будет
выполнять .NET. А COM, как вы помните, из сложной непривлекательной лобуды, ориентированной на малоквалифицированных VB-програмеров, превратился в изящную среду, органично вписывающуюся в концепции Visual C++. То же самой со временем ждет.NET.
