Здравствуйте, DJ KARIES, Вы писали:
DK>В настоящей Оберон-системе не было бы ни GDI+, ни DirectDraw7, ни Windows XP SP2.
Ибо не было бы ни нормальной графики, ни интерфейса к драйверам, ни безопасности
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Дарней, Вы писали:
AVC>>>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!". Д>>Запорожец-лимузин тоже существует. Только это не доказывает, что он годится хоть для какого-то практического использования. Д>>И вопрос звучит не "КАК это работает", а "где гарантия, что это будет работать НЕ в лабораторных условиях"
AVC>Работает же. AVC>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока. AVC>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.
Ну может быть, всё же не надо дезинформировать общественность. На Марс летал vxWorks, написанный на C.
AVC>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.
Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.
Здравствуйте, AVC, Вы писали:
AVC>Опять же Вы лично выражали несогласие с моей точкой зрения. Запамятовали?
Ну про это я уже высказывался.
Позволю себе процитировать:
На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".
Напомню еще раз — вопрос был только один: "А достаточно ли надежно это работает"? Пока что ответ был "нет, недостаточно", и никаких заслуживающих внимания аргументов против него приведено не было.
Все "зверски крутые" случаи с применением Оберона, которые тут приводились — это стерильно-лабораторные случаи, когда каждая программа тщательно проверяется и тестируется перед ее выполнением. В обычной жизни такого не будет
Должен признать, что и наши аргументы иногда неубедительны.
Я думаю, все это по причине плохой информированности.
Не нужно иметь много детальной информации, чтобы увидеть нежизнеспособность центральных концепций.
Как я опять же говорил — ОберонОС не конкурент Windows или Linux, и никогда не будет — кишка тонка. Под SymbianOS тоже веб-серверы есть. Вот только ни один фанатик не ставит ее в один разряд с серверными ОС, или хотя бы десктопными.
Так что ОберонОС так и останется нишевой ОС — в лучшем для нее случае.
C>Я привел пример кода, который вызовет ошибочную ситуацию в системе. В C>обычных ОСах система может просто прибить процесс, который эту ситуацию C>вызвал (у всех процессов — разные адресные пространства), но в ОберонОС C>этого сделать нельзя — так как нельзя автоматически определить какие C>объекты являются мусорными. Прибивать произвольные объекты тоже нельзя — C>нарушится ссылочная целостность.
А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?
Здравствуйте, Трурль, Вы писали:
Т>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?
Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Трурль, Вы писали:
Т>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?
P>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?
Здравствуйте, Sergey, Вы писали:
S>Он не ненужный, он с ошибкой — взбесился и начал немерянно отжирать память. S>И другие объекты имеют указатели, показывающие на этот объект и его части. S>Что произойдет с ними, если убить дефектный объект?
Фанаты Оберона почему-то никак не хотят разговаривать о поведении Оберона при принудительном завершении процесса (активного объекта).
Попробую порассуждать за них. Предположим, что нам удалось инициировать возникновение исключения "OopsActiveObjectDead" внутри потока исполнения.
Нормальная среда с поддержкой исключений в таком случае начинает раскручивать стек. В управляемой среде это, в частности, означает, что объекты, "спрятанные" от GC ссылками из этого стека, "выйдут из тени". При том, разумеется, условии, что никаких других ссылок на них нет. Так что в случае того самого бесконечного списка, "зацепленного" за локальную переменную, при возникновении исключения все объекты в этом списке автоматически попадут под нож GC. Кстати, не обязательно инициировать исключение внешними средствами — оно может возникнуть само, если среда поддерживает квоты: очередной NEW просто выбросит QuotaExceeded.
Однако, остаются еще проблемы:
1. Что делать, если активный объект перехватывает исключения? (Возможное решение: не поддерживать исключения; механизм раскрутки стека применять только в одном случае — убийство активного объекта. Точно так же, как винда зачищает хэндлы, открытые убитым процессом.)
2. Что делать с теми, кто держит в руках ссылку на активный объект, который внезапно умер? (Возможное решение: статус объекта становится Dead, любой метод приводит к InvalidOperationException. Плохо: его поля все еще могут держать ссылки на мусор, не давая закончить очистку.)
3. Что делать с теми, кто держит в руках ссылку на "наследство" умершего активного объекта? Если он успел передать наружу ссылку на свой бесконечный список, то убийство за превышение квоты память в систему не вернет.
4. Как определять квоты? Поскольку память в системе — общая, то невозможно провести границу принадлежности объектов активным объектам. В винде это не так — размер выделенной физической и виртуальной памяти однозначно известен.
В общем, если у AOS нет ответов на эти вопросы, то в качестве ОС общего назначения она не годится. Из-за отсутствия приемлемой изоляции между объектами. Даже если не принимать во внимание низкоуровневый стуфф типа драйверов, прямых адресов и т.п.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть C>дерево процессов, каждый процесс независим от другого (если не C>используются специальные механизмы IPC). Если мы прибиваем один процесс C>или дерево — это не влияет на остальные процессы.
Я, наконец понял, что имеется в виду. Это заняло приличное время, но я справился .
Ты думаешь, что если задачи (ну.. модули) выполняются реально в одном процессе, то у них общая память в смысле прямых указателей на объекты друг друга, да? Это не так.
Я тут щас не собираюсь защищать ОберонОС, но меня сильно смущает, что ты и WolfHound так прете против самих принципов. Софтварная изоляция — это круто, за ней будущее. По возможностям нет принципиальной разницы между хардварной и софтварной изоляции. По скорости софтварная быстрее, да да, и жрет меньше русурсов. Это понятно само по себе, и даже не нужно никаких тестов.
Вот подумай сам: в STL рассмотрена целая куча возможных ситуаций, до самых мелочей. "С копирующим конструктором и без", "простой класс объектов и сложный", "где лежит контейнер". А теперь предлагаешь, чтобы в Обероне, как "в убогой университетской поделке с устаревшим синтаксисом того еще Паскаля", всё было сделано в лоб: один процесс на ОС и на задачи, без многозадачности, с прямыми указателями на объекты ядра и драйверами на C++? Хи-хи получается .
Здравствуйте, Cyberax, Вы писали:
C>В обычных ОСах система может просто прибить процесс, который эту ситуацию C>вызвал (у всех процессов — разные адресные пространства), но в ОберонОС C>этого сделать нельзя — так как нельзя автоматически определить какие C>объекты являются мусорными. Прибивать произвольные объекты тоже нельзя — C>нарушится ссылочная целостность.
А если подумать?
1) ГЦ (по определению) знает весь граф связей между объектами (в каждый момент времени).
2) Решение о прибивании неугодного объекта принимает либо система, либо пользователь, но не ГЦ (он тут не причем).
3) После того как принято решение об убивании неугодного объекта, благодаря доступной ГЦ информации о графе связей объектов, можно найти связную компоненту графа внутри которой находится неугодный объект.
4) Уничтожению подлежит именно эта компонента связности графа объектов — забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач перестает выделять процессорное время для активных объектов принадлежащей этой компоненте связности.
5) Как только мы о ней "забыли", ГЦ ее уничтожил. И дело с концом.
Таким образом, для убивания неугодных объектов совершенно не важно сколько адресных пространств.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А ведь и в правду работает, а вот почему — это уже технические вопросы, за ответами обращайтесь к документации по конкретным системам.
Т.е. по существу ответить не можем — сидите сами придумывайте ответы на ваши вопросы, так? Т.е. кроме слепой веры в то, что "работает", ничего нет?
Супер
Hello, Сергей!
You wrote on Thu, 27 Jan 2005 09:29:23 GMT:
СГ> 1) ГЦ (по определению) знает весь граф связей между объектами (в каждый СГ> момент времени). 2) Решение о прибивании неугодного объекта принимает СГ> либо система, либо пользователь, но не ГЦ (он тут не причем). 3) После СГ> того как принято решение об убивании неугодного объекта, благодаря СГ> доступной ГЦ информации о графе связей объектов, можно найти связную СГ> компоненту графа внутри которой находится неугодный объект. 4) СГ> Уничтожению подлежит именно эта компонента связности графа объектов - СГ> забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач СГ> перестает выделять процессорное время для активных объектов СГ> принадлежащей этой компоненте связности. 5) Как только мы о ней СГ> "забыли", ГЦ ее уничтожил. И дело с концом.
Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро
прибиваем нафиг? Здорово.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...
Да, я тоже за это. И слабо понимаю, как можно быть против .
Хардварная изоляция нужна для одного: поддерживать старые проги (чтобы играть в Doom2 ).
Здравствуйте, Sergey, Вы писали:
S>Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро S>прибиваем нафиг? Здорово.
S>With best regards, Sergey.
Не думаю. Сейчас нам расскажут, что нет там никаких Callback.
Если поискать как следует, то можно найти прецеденты: нет памяти, нет процессов, и т. д. Сползаем (в который раз!) на уровень обсуждения сферических коней в вакууме...
Здравствуйте, Шахтер, Вы писали:
AVC>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.
Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.
С++ конечно НЕ язык для детской песочницы, но наиболее крупные и сложные проекты как писались так и пишуться на C (не С++), одним из оснований является тот факт, что компилятор ANSI C найдется на любой платформе, хоть на специфической ОС для марсохода.
С++ в большей степени использовали и используют для т.н. 'сервисного' программирования, но этот кусок уже давно "отъедают" Java и .NET.
Здравствуйте, Privalov, Вы писали:
Т>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить? P>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?
А чем в этом отношении Оберон хуже?
В Обероне "плохой" процесс убивается, в Log выводится trap text.
В данном пункте не вижу разницы.
А вопрос Трурль задал правильный.
Противники Оберона постоянно высказываются в том духе, что "убийство процесса" есть главный (чуть ли не единственный) механизм безопасности в ОС.
Вот Трурль и задает простой вопрос: как процесс становится "плохим", когда его пора убивать?
У меня есть некоторое опасение, что в полном объеме эта задача может оказаться и алгоритмически неразрешимой.
Кроме того, такие большие надежды на отдельные адресные пространства в чем-то разумны, а в чем-то немного наивны.
Видимо, следует полагать, что "плохой" процесс либо вовсе не взаимодействует с другими процессами, либо его "плохость" на них почему-то совсем не влияет.
Ведь не только передача другому процессу указателя, но и передача любых ошибочных данных влияет на работу других процессов и системы в целом.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Шахтер, Вы писали:
AVC>>Работает же. AVC>>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока. AVC>>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.
Ш>Ну может быть, всё же не надо дезинформировать общественность. На Марс летал vxWorks, написанный на C.
(С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не дезинформировать общественность.
Действительно, некоторые страны (мне известно о Канаде и UK) ограничивают применение Си/Си++ в критических областях, прежде всего в области ПО для атомной энергетики.
AVC>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п. Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.
И какие из них САМЫЕ КРУПНЫЕ?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
.
.
