Hello, AVC!
You wrote on Thu, 27 Jan 2005 11:18:09 GMT:
A> А чем в этом отношении Оберон хуже? A> В Обероне "плохой" процесс убивается, в Log выводится trap text.
Вопрос уже задавали — что происходит с другими процессами, в которых есть
указатели, ссылающиеся на данные в этом процессе.
A> В данном пункте не вижу разницы. A> А вопрос Трурль задал правильный. A> Противники Оберона постоянно высказываются в том духе, что "убийство A> процесса" есть главный (чуть ли не единственный) механизм безопасности в A> ОС. Вот Трурль и задает простой вопрос: как процесс становится "плохим", A> когда его пора убивать?
Например, если юзер захотел — типа adware какое-нибудь обнаружил. Данное
adware успело зарегистрировать коллбэки на все, на что смогло. Как его
срубить, если GC при этом потянит за одной задачей полсистемы?
A> У меня есть некоторое опасение, что в полном объеме эта задача A> может оказаться и алгоритмически неразрешимой.
Что с того? Частные случаи, когда необходимо уметь прибить процесс в любом
случае достаточно важны.
A> Кроме того, такие большие A> надежды на отдельные адресные пространства в чем-то разумны, а в чем-то A> немного наивны.
Примерно как предохранитель на пистолете — немного наивно, но без него
запросто себе же яйца отстрелишь.
A> Видимо, следует полагать, что "плохой" процесс либо A> вовсе не взаимодействует с другими процессами, либо его "плохость" на A> них почему-то совсем не влияет. Ведь не только передача другому процессу A> указателя, но и передача любых ошибочных данных влияет на работу A> других процессов и системы в целом.
Влияет, конечно. Но в системах с разделением адресных пространств задачи
устроены так, что это влияние в большинстве случаев не является
катастрофическим. Потому что на GC и безопасные языки программирования никто
не надеется и напрямую в память других процессов не лазит. Ну и помимо
разных адресных пространств в "нормальных" операционках еще куча барьеров и
рогаток предусмотрена.
Например, упал екзешник посреди EnumChildWindows — однако подсистеме user
ничего плохого не делается. Очевидно, что один GC в такую ситуацию не сможет
разрешить, необходимы другие механизмы. Однако некоторые почему-то
утверждают обратное.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Ну и почти по теме ветки (чтоб совсем в оффтоп не скатываться): хотел выразить свой респект господину AVC (даже несмотря на то, что он меня слегка обгадил )
Чувствую себя немного свиньей...
Но, по замыслу, это был не личный выпад, конечно.
Просто хотел обратить внимание общественности, что Си++ "разрешено" и "просто так" любить, а Оберон — почему-то нельзя, даже если у этого языка (и у одноименной системы тоже) есть свои достоинства.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Sergey, Вы писали:
A>> А чем в этом отношении Оберон хуже? A>> В Обероне "плохой" процесс убивается, в Log выводится trap text. S>Вопрос уже задавали — что происходит с другими процессами, в которых есть S>указатели, ссылающиеся на данные в этом процессе.
Вы, наверное, имеете в виду статические указатели, разделяемые между разными процессами. (В отношении стековых указателей мы уже выяснили, что ничего страшного произойти не должно.)
Здесь и правда есть проблема.
Но она опять же несколько сложнее, чем видится критикам.
Откуда уверенность, что, если процесс сделал что-то "плохое", то и все установленные им статические указатели тоже "плохие"?
А если они — "хорошие"? Если они очень нужны для корректной работы остальных процессов?
Как отделить, так сказать, "овец от козлищ"?
"Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я в ней сомневаюсь. )
Хочу особенно обратить Ваше внимание, что нам (гадким сторонникам Оберона, бякам-букам и т.п.) было бы очень легко угодить взыскательному вкусу критиков. Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.)
И никаких проблем со статическими указателями!
Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей в Обероне — ациклическая.
Не потребуется даже менять текст программ.
Просто настроить динамический загрузчик: грузи модули ядра один раз, а остальные — по одному на каждое импортирующее его приложение.
Если такое приложение выгрузить, то все его модули могут быть выгружены тоже.
При этом Оберон по-прежнему остается быстрее Линукса и т.д., т.к. адресное пространство остается единым. (Просто переменные одного процесса недоступны переменным другого.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Sergey, Вы писали:
A>>> А чем в этом отношении Оберон хуже? A>>> В Обероне "плохой" процесс убивается, в Log выводится trap text. S>>Вопрос уже задавали — что происходит с другими процессами, в которых есть S>>указатели, ссылающиеся на данные в этом процессе.
AVC>Вы, наверное, имеете в виду статические указатели, разделяемые между разными процессами. (В отношении стековых указателей мы уже выяснили, что ничего страшного произойти не должно.)
Я так и не понял что такое "статические указатели", если указатели, являющиеся стат. переменными, то непонятно, как же решилась проблема со обычными стековыми переменными? Если есть переменная в другом процессе в стеке, что с ней будет? Никакого объяснения я что-то не припомню...
Поясните, может я чего не заметил за всей этой перепалкой.
Hello, AVC!
You wrote on Thu, 27 Jan 2005 12:45:48 GMT:
A>>> А чем в этом отношении Оберон хуже? A>>> В Обероне "плохой" процесс убивается, в Log выводится trap text. S>> Вопрос уже задавали — что происходит с другими процессами, в которых S>> есть указатели, ссылающиеся на данные в этом процессе.
A> Вы, наверное, имеете в виду статические указатели, разделяемые между A> разными процессами. (В отношении стековых указателей мы уже выяснили, A> что ничего страшного произойти не должно.) Здесь и правда есть проблема. A> Но она опять же несколько сложнее, чем видится критикам.
Она, вдобавок, несколько сложнее, чем видится некоторым защитникам
A> Откуда уверенность, что, если процесс сделал что-то "плохое", то и A> все установленные им статические указатели тоже "плохие"?
Это ты Губанова спрашивай — он говорил, что модуль выгружать будем. Заодно и
все модули, на которые GC укажет.
A> А если они — "хорошие"? Если они очень нужны для корректной работы A> остальных процессов?
Вот и я о том же — что, если они очень нужны для корректной работы остальных
процессов?
A> Как отделить, так сказать, "овец от козлищ"?
Вот пока защатники Оберона этого не показали.
A> "Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я A> в ней сомневаюсь. )
Аналогично.
A> Хочу особенно обратить Ваше внимание, что нам (гадким сторонникам A> Оберона, бякам-букам и т.п.) было бы очень легко угодить взыскательному A> вкусу критиков. Достаточно было бы разрешить повторно грузиться всем A> модулям, кроме модулей ядра (т.к. ядро — одно на всех.) И никаких A> проблем со статическими указателями!
Зато появляется куча других проблем.
A> Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей A> в Обероне — ациклическая.
Т.е., коллбэков и подобного нет в принципе?
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Курилка, Вы писали:
AVC>>Вы, наверное, имеете в виду статические указатели, разделяемые между разными процессами. (В отношении стековых указателей мы уже выяснили, что ничего страшного произойти не должно.) К>Я так и не понял что такое "статические указатели", если указатели, являющиеся стат. переменными, то непонятно, как же решилась проблема со обычными стековыми переменными? Если есть переменная в другом процессе в стеке, что с ней будет? Никакого объяснения я что-то не припомню... К>Поясните, может я чего не заметил за всей этой перепалкой.
"Статические" (в смысле Си) указатели — это указатели, являющиеся переменными какого-нибудь модуля, а не стековыми переменными.
Т.е. именно то, что Вы и предположили.
Теперь о стековых указателях.
Стековый указатель "сбрасывается" при выходе из соответствующей процедуры, или при обработке исключения.
Насколько я догадываюсь, это может быть задачей эпилога процедуры.
Т.е. при выходе из процедуры, нормальном завершении или "убийстве" процесса по исключению, все стековые указатели становятся недействительными и не представляют проблемы для GC.
Другое дело — статические указатели.
Т.к. модуль может обслуживать несколько процессов (потоков, в терминологии Windows), то указатель не "умирает" вместе с процессом.
Этот факт и является "яблоком раздора".
Как я уже писал, эта проблема легко (IMHO, конечно ) решается разрешением повторной загрузки (и последующей выгрузки) прикладных модулей.
К тому же, это очень удобно для разработчиков: перекомпилировал модуль, и он сразу готов для употребления. Причем сразу всеми приложениями. Ведь в Обероне, как и в Смоллтоке, статическая линковка необязательна.
Но при этом растет объем требуемой оперативной памяти и затрудняется межпроцессное взаимодействие. (Т.е. происходит примерно то же, что в "нормальных", как кто-то тут сказал, ОС.)
Информации по тонкостям современных многозадачных Оберон-систем у нас недостаточно.
Вот мы и стараемся ее "нарыть", в промежутках между основной работой. Ищем "доки", проводим эксперименты и т.д.
Иногда пытаемся предложить свое (м.б., наивное ) решение.
И только если будет доказано, что наши поиски бесполезны, вернемся к указанному "безопасному" варианту.
Т.е. находимся в поиске .
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Sergey, Вы писали:
A>> Но она опять же несколько сложнее, чем видится критикам. S>Она, вдобавок, несколько сложнее, чем видится некоторым защитникам
A>> Как отделить, так сказать, "овец от козлищ"? S>Вот пока защатники Оберона этого не показали.
Никто этого пока здесь не показал.
Вопрос Трурля так и повис в воздухе.
A>> "Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я A>> в ней сомневаюсь. ) S>Аналогично.
S>Зато появляется куча других проблем.
Наверное. А каких именно?
A>> Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей A>> в Обероне — ациклическая. S>Т.е., коллбэков и подобного нет в принципе?
А вот здесь связи нет.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.)
Ересь какая...
Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон. Для "множественности" придумано ООП. Создаете столько объектов сколько хочется и работаете с этим множеством контекстов. А модуль — это всего лишь вместилище кода, который сам по себе "не обладает свободой воли".
AVC> И никаких проблем со статическими указателями!
Здравствуйте, Сергей Губанов, Вы писали:
AVC>>Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.) СГ>Ересь какая... СГ>Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон. Для "множественности" придумано ООП. Создаете столько объектов сколько хочется и работаете с этим множеством контекстов. А модуль — это всего лишь вместилище кода, который сам по себе "не обладает свободой воли".
Я просто обозначил "предельную черту".
Если мы переступим ее, то предшествующая критика Оберона потеряет силу.
А выгоды, тем не менее, останутся!
Например, системный вызов останется таким же быстрым.
Значит, Оберон-система — уже не глупость.
Т.е. я хотел показать критикам тот максимум, которого они могут достигнуть.
(В отношении же языка Оберон, вся критика уперлась в отсутствие шаблонов. У Windows-приложения на Обероне нет никаких "проблем со статическими указателями", т.к. это приложение — отдельный процесс в смысле Windows.)
AVC>> И никаких проблем со статическими указателями! СГ>А проблем и так нет.
Ну, попутали меня бесы!
С точки зрения критиков — они есть.
Они верят: если процесс убить — станет хорошо.
А если два процесса — еще лучше, наверное.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Денис Федин, Вы писали:
ДФ>Здравствуйте, Шахтер, Вы писали:
AVC>>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.
Ш>>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.
ДФ>С++ конечно НЕ язык для детской песочницы, но наиболее крупные и сложные проекты как писались так и пишуться на C (не С++), одним из оснований является тот факт, что компилятор ANSI C найдется на любой платформе, хоть на специфической ОС для марсохода.
Вот забавно-то, проект значит крупный и сложный, а выполняется он на Си только из-за того что для выбранной платформы компилятора другого может не оказаться! Курам на смех! Да это значит вовсе никакой не крупный проект, а так рядовая коммерческая работа.
Вот по настоящему крупный и сложный проект — это когда есть новое голое железо, под которое надо написать все — и новую операционку, и новый компилятор нового языка (на самом себе), и прикладные программы. Именно в результате такой работы на свет появилась ОС Оберон и язык программирования Оберон. Именно поэтому они такие какие есть — все необходимое и достаточное в них есть, а лишних погремушек нет.
Здравствуйте, AVC, Вы писали: AVC>А чем в этом отношении Оберон хуже?
Оберон хуже тем, что благодаря единому адресному пространству невозможно определить "владельца" ресурса. Поэтому невозможно, например, раздать квоты. AVC>В Обероне "плохой" процесс убивается, в Log выводится trap text. AVC>В данном пункте не вижу разницы.
Разница в том, что в "обычной ОС" на этом этапе прибиваются все разделяемые ресурсы, захваченные убитым процессом. В Обероне в лучшем случае удастся отпустить ссылки, которыми владел убиваемый активный объект. Порожденные им объекты, доступные из других активных объектов, продолжат свое существование. Давайте рассмотрим абстрактный пример: наш активный объект создал окно. Конечно же, он передал ссылку на окно оконной подсистеме, чтобы та могла (к примеру) показать это окно в таскбаре. Случилось так, что АО должен умереть. Ок, теперь у нас осталась только одна ссылка на окно: та, что из оконной подсистемы. Упс, процесс умер, но окна его живут. А? AVC>А вопрос Трурль задал правильный. AVC>Противники Оберона постоянно высказываются в том духе, что "убийство процесса" есть главный (чуть ли не единственный) механизм безопасности в ОС.
Нет. Главный механизм безопасности ОС — это изоляция песочниц друг от друга. Это позволяет время от времени делать уборку в песочнице, не трогая остальные. Идеальная ОС с единым адресным пространством в общем случае создает полносвязный граф. Рассуждения СГ об определении компоненты связности
- детский лепет. В простейшем случае, убиваемый объект владеет ссылкой на System (MyComputer, Core — неважно что там еще). И эта "компонента связности" займет весь граф. Упс, добро пожаловть в BSOD.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Сергей Губанов, Вы писали: СГ>А если подумать?
СГ>1) ГЦ (по определению) знает весь граф связей между объектами (в каждый момент времени). СГ>2) Решение о прибивании неугодного объекта принимает либо система, либо пользователь, но не ГЦ (он тут не причем). СГ>3) После того как принято решение об убивании неугодного объекта, благодаря доступной ГЦ информации о графе связей объектов, можно найти связную компоненту графа внутри которой находится неугодный объект. СГ>4) Уничтожению подлежит именно эта компонента связности графа объектов — забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач перестает выделять процессорное время для активных объектов принадлежащей этой компоненте связности. СГ>5) Как только мы о ней "забыли", ГЦ ее уничтожил. И дело с концом.
СГ>Таким образом, для убивания неугодных объектов совершенно не важно сколько адресных пространств.
Нда. Наукообразно, но бессмысленно.
1. Что делать, если эта компонента связности включает в себя популярные объекты — типа Screen, Printer, Disk? Что останется в памяти после убийства всех этих компонент?
2. Что такое "обнуление корневых ссылок"? Вот у меня есть объект А. К примеру, это DeskTop. Я передаю ему ссылку на свое окно, поскольку именно десктоп берет на себя управление окнами. Вот меня надо убить. Ясно, что мое окно входит в компоненту связности — у меня есть ссылка на него, да и окно ссылается на своего автора. Угу. А DeskTop ссылается на окно. Какую из ссылок ты будешь обнулять?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот забавно-то, проект значит крупный и сложный, а выполняется он на Си только из-за того что для выбранной платформы компилятора другого может не оказаться! Курам на смех! Да это значит вовсе никакой не крупный проект, а так рядовая коммерческая работа.
В моем понимании крупный и сложный проект это разработка "с нуля" ОС, СУБД, OpenGL и т.д.
Наверное это в вашем понимании рядовая коммерческая работа.
СГ>Вот по настоящему крупный и сложный проект — это когда есть новое голое железо, под которое надо написать все — и новую операционку, и новый компилятор нового языка (на самом себе), и прикладные программы. Именно в результате такой работы на свет появилась ОС Оберон и язык программирования Оберон. Именно поэтому они такие какие есть — все необходимое и достаточное в них есть, а лишних погремушек нет.
Hello, AVC!
You wrote on Thu, 27 Jan 2005 13:22:24 GMT:
A> Никто этого пока здесь не показал. A> Вопрос Трурля так и повис в воздухе.
Да это, в общем, не так и важно. Важно, как именно можно выгрузить задачу,
если такая необходимость возникла.
S>> Зато появляется куча других проблем.
A> Наверное. А каких именно?
В первую очередь — восстановление состояния. В общем случае задача, IMHO, не
решается. Значит, в каждом частном случае заниматься этим придется
разработчику модуля. А это ни к чему хорошему не приведет.
A>>> Тем более, все это очень хорошо "вяжется" с тем, что зависимость A>>> модулей в Обероне — ациклическая. S>> Т.е., коллбэков и подобного нет в принципе?
A> А вот здесь связи нет.
Почему это нет? Я уже приводил пример — некий модуль начал выполнять что-то
вроде EnumChildWindows, во время которого его убили. Если следовать
рекомендациям Губанова, следует заодно убить с помощью GC все модули,
которые ссылаются на дефектный модуль. Т.е., убиваем модуль user или что там
вместо него у нас будет. А потом, возможно, пытаемся загрузить его снова —
только все открытые окошки при этом тю-тю (это к вопросу о восстановлении
состояния).
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и кричите: "Этого не может быть потому что этого не может быть никогда!"
Вспомните, чем отличается принцип построения той же самой Aos BlueBottle от традиционных Windows/UNIX. В традиционных Windows/UNIX поверх железа работает ядро операционки, поверх ядра работают рантайм системы для разных программ написанных на всяких языках программирования, в этих рантайм системах выполняются приложения.
Железо ->- Ядро ->- Рантайм(ы) ->- Приложения
Ядро пишется на Си или вообще на ассемблере. Приложения уже можно писать на ЯВУ.
В Aos BlueBottle все наоборот, там поверх железа работает рантайм система языка программирования Active Oberon.
Железо ->- Active Oberon runtime system ->- Модули операционки + модули приложений
Операционка и ее приложения целиком пишутся на ЯВУ Active Oberon и исполняются в одной и тойже среде исполнения. Рантайм система не видит разницы между объектами операционки и объектами приложений. Модули самой ОС с точки зрения рантайм системы ни чем не отличаются от модулей приложений.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Sergey, Вы писали:
S>>Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро S>>прибиваем нафиг?
СГ>А что, страшно, да?
СГ>Подумаешь, перезапустим пару-тройку системных объектов...
СГ>Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и кричите: "Этого не может быть потому что этого не может быть никогда!"
Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом движении надо было тачку перезагружать
Это кайф
Здравствуйте, Sinclair, Вы писали:
AVC>>А чем в этом отношении Оберон хуже?
S>Оберон хуже тем, что благодаря единому адресному пространству невозможно определить "владельца" ресурса.
С какой стати?
Каким макаром вдруг адресные пространства связаны с владельцами ресурсов?
S> В простейшем случае, убиваемый объект владеет ссылкой на System (MyComputer, Core — неважно что там еще). S> И эта "компонента связности" займет весь граф. Упс, добро пожаловть в BSOD.
Вот именно, что это он обладает ссылкой на нее, а не она обладает ссылко на него. Он ей безразличен. Компонента связности в точности равна аналогичному понятию ПРОЦЕССА в Windows/UNIX. Как Windows/UNIX процессы не знают друг о друге, так же и тут, одна компонента связности графа объектов не знает о других.
Здравствуйте, Sinclair, Вы писали:
S> К примеру, это DeskTop. Я передаю ему ссылку на свое окно, поскольку именно десктоп берет на себя управление окнами. Вот меня надо убить. Ясно, что мое окно входит в компоненту связности — у меня есть ссылка на него, да и окно ссылается на своего автора. Угу. А DeskTop ссылается на окно. Какую из ссылок ты будешь обнулять?
А что если я отвечу на этот вопрос? Вы свою шляпу обещаете съесть?
Hello, Сергей!
You wrote on Thu, 27 Jan 2005 14:23:58 GMT:
S>> Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, S>> ядро прибиваем нафиг?
СГ> А что, страшно, да?
Ну, давай перезапустим подсистему, аналогичную виндовской user или gdi.
Заодно придется перезапускать все программы, которые их используют. Для
юзера это ничем не будет отличаться от перезагрузки системы.
СГ> Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и СГ> кричите: "Этого не может быть потому что этого не может быть никогда!"
Да почему же не может? Как раз в падучесть систем без разделения адресных
пространств я вполне верю
СГ> Операционка и ее приложения целиком пишутся на ЯВУ Active Oberon и СГ> исполняются в одной и тойже среде исполнения. Рантайм система не видит СГ> разницы между объектами операционки и объектами приложений.
Тем хуже для нее.
СГ> Модули самой ОС с точки зрения рантайм системы ни чем не отличаются от СГ> модулей приложений.
Тоже фигово.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
)
)
.
