Системный список указателей на пользовательские объекты можно написать так, чтобы он автоматически забывал о плохом объекте, псевдокод:
Для каждого указателя из системного списка выполнить:
извлечь указатель из списка и присвоить его значение вспомогательному временному указателю
разыменовать вспомогательный указатель и что-нибудь поделать, например, попытаться нарисовать View если это она
(* в этом месте возникнет трап если объект не валиден *)
вернуть значение вспомогательного указателя обратно в список указателей
Если случился трап, то плохой указатель назад в системный список возвращен не будет, далее система будет работать как ни в чем не бывало, а ГЦ приберет что надо.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Курилка, Вы писали:
К>>> Ага, а как же пример с десктопом — он знает об окне, но десктоп не удаляется...
СГ>>Значит сделано по умному.
К>Вот и давайте будем поклоняться умному Вирту! К>Мы не знаем как оно работает, но ведь великая вещь!
There is a story (which I quote from memory, may not have all the details right) about a talk that Niklaus Wirth gave at Apple Computer about Oberon. He was some way into the talk when a chap at the back stood up and said, "So you say that Oberon doesn't have inheritance?"
Wirth, "No, that's right"
"And it doesn't have..." (insert here various things that Ruby and Smalltalk have, but Oberon doesn't).
Wirth agreed.
"Then how can you say that it is an Object-Oriented Language?"
To which Wirth replies, "Well, who can say what is, and what isn't, an OO language?"
Chap says, "I can, I'm Alan Kay, and I invented the term"
Здравствуйте, Cyberax, Вы писали:
C>А что будет у нас в Обероне, если прибить модуль System, например?
Таки отвечу вопросом на вопрос.
Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе?
Ибо некошерно.
AVC пишет:
> Ш>Ну может быть, всё же не надо дезинформировать общественность. На > Марс летал vxWorks, написанный на C. > (С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не > дезинформировать общественность. > Действительно, некоторые страны (мне известно о Канаде и UK) > ограничивают применение Си/Си++ в критических областях, прежде всего в > области ПО для атомной энергетики.
В этих областях вообще все ограничивают. И большую часть софта пишут на Ada.
> Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и > сложные проекты. > И какие из них *САМЫЕ КРУПНЫЕ*?
DJ KARIES пишет:
> C>А что будет у нас в Обероне, если прибить модуль System, например? > Таки отвечу вопросом на вопрос. > Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе? > Ибо некошерно.
lsass может прибить только администратор (проверьте сами ), а вот в
OberonOS — все равны, привиллегий нет.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Класс! ЗХ>Даже если это и анекдот, то великолепный! ЗХ>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.
Здравствуйте, prVovik, Вы писали:
V>Неужели, они ситсемы реального времени пишут на Обероне?
hard-real time system XO/2 написана на Обероне. V>Короче, ГЦ и СРВ — это вещи несовместимые.
И, представьте себе, со сборщиком мусора.
Здравствуйте, Трурль, Вы писали:
ЗХ>>Класс! ЗХ>>Даже если это и анекдот, то великолепный! ЗХ>>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами ) Т>
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.
Это реальная история, ставшая фольклором.
Вторая ссылка содержит рассказ очевидца, так что действительность довольно близка к байке:
I was in the room when this happened, some time in the second half of the 1980s. The presentation was on Oberon, before anyone had really heard of it. It was basically a "what I did on my summer vacation" talk given by a quality engineer who had dropped by Wirth's lab while he was vacationing in Europe. The announcement really played up that this was the next big object-oriented system, so that's why Alan lowered the boom on the guy like that. The thing that amazed me was that the presenter just went right on like nothing had happened. I think I would have gathered up my slides, thanked the audience, and walked out!
I recall Alan's answer as being more like "Well, I invented the term, so I think I have something to say about it." He did NOT say his name, and I don't think most of the folks in the room recognized him (including the presenter), so the, um, impact of his statement was perhaps not as great as one might expect. Steve and I got a really good chuckle out of it though.
-- JoshuaSusser
ЗХ>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )
Там чел сам напросился.
А насчет жавы Кей высказывался мимоходом в одной из своих лекций.
Типа того, что она годится разве что для курсов выходного дня. Но ее не стоит преподавать в университетах и преподносить как какое-то достижение в Computer Science.
Также там звучали слова вроде boring, harm, и т.д.
Трурль пишет:
> V>Неужели, они ситсемы реального времени пишут на Обероне? > hard-real time system XO/2 написана на Обероне. > V>Короче, ГЦ и СРВ — это вещи несовместимые. > И, представьте себе, со сборщиком мусора.
Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в
2 раза по памяти, по сравнению с non-realtime GC).
Здравствуйте, Sinclair, Вы писали:
S>Разница в том, что в "обычной ОС" на этом этапе прибиваются все разделяемые ресурсы, захваченные убитым процессом. В Обероне в лучшем случае удастся отпустить ссылки, которыми владел убиваемый активный объект. Порожденные им объекты, доступные из других активных объектов, продолжат свое существование. Давайте рассмотрим абстрактный пример: наш активный объект создал окно. Конечно же, он передал ссылку на окно оконной подсистеме, чтобы та могла (к примеру) показать это окно в таскбаре. Случилось так, что АО должен умереть. Ок, теперь у нас осталась только одна ссылка на окно: та, что из оконной подсистемы. Упс, процесс умер, но окна его живут. А?
Но сначала несколько вводных фраз.
Со вчерашнего дня я начал совершать "тарутинский маневр" , предложив загружать новую копию прикладного модуля (т.е. не модуля ядра) для каждого запускаемого приложения.
Сергей (Губанов) сгоряча даже заподозрил меня в "ереси".
Но цель у меня другая, не "ревизионистская", а тактическая.
Поскольку вопрос о статических указателях оказался не таким простым (по крайней мере, для меня ), я решил разобраться сначала с более простым вариантом единого адресного пространства.
Какими особенностями обладает предлагаемый подход?
Процессы уже не могут взаимодействовать друг с другом напрямую, минуя специальные механизмы межпроцессного взаимодействия, находящиеся под контролем ядра ОС.
Ведь чтобы взаимодействовать напрямую, процессы должны иметь прямой доступ к разделяемым ими переменным.
А такого доступа нет. Ведь у каждого процесса своя копия статических переменных общих прикладных модулей.
По завершении работы процесса все его прикладные модули могут быть безбоязненно выгружены, т.к. не используются более ни одним процессом.
Такое решение кажется очень похожим на разделяемые адресные пространства, практикуемые "нормальными" ОС.
Но есть одно существенное различие. Все приложения по-прежнему находятся в одном адресном пространстве с ядром ОС.
Не требуется никакого переключения контекста для вызова системных функций.
Защита приложений друг от друга осуществляется единственно надежностью статической и динамической типизации Оберона.
Т.е. в самом существенном пункте это по-прежнему Обероновский, а не "нормальный" подход.
Ведь нетрудно сделать умозаключение по принципу ассоциативности и сделать вывод: если все приложения находятся в одном адресном пространстве с ядром ОС, то в данной системе и существует только одно адресное пространство, а не множество пространств, как это обстоит в "нормальных" системах.
(Мне кажется, что Сергей своими рассуждениями о "компонентах связности" пытался выразить сходную мысль, но ему несколько помешала его горячность.)
Ясно, что вызов процедур ядра по-прежнему будет очень быстрым.
Для экономии памяти можно предложить, чтобы код одного и того же модуля (если он не менялся) был представлен лишь однажды. Копии создаются только для сегментов данных.
К сожалению, межпроцессное взаимодействие существенно усложняется, но не более, чем в "нормальных" ОС.
Вот теперь, вооружившись таким подходом, попытаемся разобраться в Вашем вопросе.
Упомянутая Вами оконная система, в которой сохранилась ссылка на убитое окно, может содержаться либо в прикладных модулях (вроде того, как раньше ваяли вполне приличные графические приложения под DOS Extender'ом ), либо в модулях ядра (вроде того, как сейчас в "Виндах").
В первом случае, проблема решается автоматически, т.к. модули оконной системы выгружаются вместе с приложением.
Во втором случае, решение проблемы не намного сложнее. Ядро хранит указатель на объект приложения вместе с указателем на дескриптор соответствующего приложения. Когда работа приложения завершается (в т.ч. по причине "плохого поведения" ), ядро рассылает всем своим контейнерам broadcast-овое сообщение: удалить все указатели на объекты, связанные с таким-то дескриптором процесса.
Как видите, в обоих мыслимых случаях решение проблемы не представляет труда. (По крайней мере, мне так сейчас кажется. )
При этом вовсе не требуется введения отдельных адресных пространств, которые следовало бы бдительно отслеживать.
Я хочу надеяться, что предлагаемый подход побудит многих принять идею единого адресного пространства хотя бы в принципе.
А затем уже мы вернемся к обсуждению ситуации с единственной копией каждого модуля в оперативной памяти.
Я вполне допускаю (и допускал) мысль, что не всегда можно ограничиться единственной копией модуля.
Но хочу исследовать этот вопрос более детально.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
C>Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в C>2 раза по памяти, по сравнению с non-realtime GC).
Возможен с бааальшим оверхедом, а возможен и с небольшим. В XO/2 выбрали второе.
Трурль пишет:
> C>Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в > C>2 раза по памяти, по сравнению с non-realtime GC). > Возможен с бааальшим оверхедом, а возможен и с небольшим. В XO/2 > выбрали второе.
Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x
оверхедом. Синхронный — возможен и с меньшим, но и там сложно дать
жесткие временные гарантии — проблемы появляются в случаях, когда GC
нужно прерывать во время его работы.
Вообще, GC для realtime не стоит использовать — не нужен он там.
Здравствуйте, Cyberax, Вы писали:
C>AVC пишет:
C>В этих областях вообще все ограничивают. И большую часть софта пишут на Ada.
И на Модула-2.
Собственно, только Ада и Модула-2 "разрешены" повсеместно.
Говорят, что дело прежде всего в наличии у них стандартов ISO.
>> Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и >> сложные проекты. >> И какие из них *САМЫЕ КРУПНЫЕ*?
C>Windows, например Да вообще почти весь софт.
Изначально Windows были написаны на Паскале.
Затем переписаны на Си.
Сейчас некоторая часть Windows написана на Си++.
Значит ли это, что Windows — именно Си++-ный проект?
Вряд ли.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и >>> сложные проекты. >>> И какие из них *САМЫЕ КРУПНЫЕ*? > C>Windows, например Да вообще почти весь софт. > Изначально Windows были написаны на Паскале. > Затем переписаны на Си.
Врут Легенда родилась из-за распространенности PASCAL calling
convention в Винде.
> Сейчас *некоторая* часть Windows написана на Си++.
Да, а остальная — на C&asm.
> Значит ли это, что Windows — именно Си++-ный проект? > Вряд ли.
Тут ссылки уже приводили У Adobe'а все продукты на С++, например.
Hello, AVC!
You wrote on Fri, 28 Jan 2005 11:54:28 GMT:
A> а тактическая. Поскольку вопрос о статических указателях оказался не A> таким простым (по крайней мере, для меня ), я решил A> разобраться сначала с более простым вариантом единого адресного A> пространства. Какими особенностями обладает предлагаемый подход?
Собственно, к единому адресному пространству как таковому у меня, например,
претензий не было. Я несогласен с другим утверждением — "GC и строгая
типизация достаточны для реализации надежной ОС с единым адресным
пространством, при это все модули, включая ядро, для рантайма равноценны. И
дохлых указателей при этом не бывает". Именно это, как мне показалось,
пытался утверждать Губанов.
A> [q] A> Процессы уже не могут взаимодействовать друг с другом A> напрямую, минуя специальные механизмы межпроцессного A> взаимодействия, находящиеся под контролем ядра ОС. Ведь чтобы A> взаимодействовать напрямую, процессы должны иметь прямой A> доступ к разделяемым ими переменным. А такого доступа нет. Ведь у A> каждого процесса своя копия статических переменных общих прикладных A> модулей. По завершении работы процесса все его прикладные модули могут A> быть безбоязненно выгружены, т.к. не используются более ни одним A> процессом. Такое решение кажется очень похожим на разделяемые адресные A> пространства, практикуемые "нормальными" ОС. Но есть одно A> существенное различие. Все приложения по-прежнему находятся в A> одном адресном пространстве с ядром ОС.
...что на платформе х86 не так уж и здорово по причине этого самого
адресного пространства ограниченности.
A> Не требуется никакого переключения контекста для вызова системных A> функций. Защита приложений друг от друга осуществляется единственно A> надежностью статической и динамической типизации Оберона.
Этого не достаточно. Поскольку раз некоторые объекты убиваются не по
алгоритмам сборки мусора, могут образоваться висящие указатели. В принципе,
я могу представить GC, который висящих указателей даже в такой ситуации не
допустит и, скажем, их обнулит. Но это опять-таки перекладывание проблемы на
программиста — он то может и не ожидать, что у него объекты, ссылки на
которые он держит, пропадать начнут и вместо вызова их методов полетят
исключения.
A> модули оконной системы выгружаются вместе с приложением. Во втором A> случае, решение проблемы не намного сложнее. Ядро хранит указатель на A> объект приложения вместе с указателем на дескриптор соответствующего A> приложения.
То бишь, подобие хэндла. Но, IMHO, пока далекое от совершенства.
A> Когда работа приложения завершается (в т.ч. по причине "плохого A> поведения" ), ядро рассылает всем своим контейнерам broadcast-овое A> сообщение: удалить все указатели на объекты, связанные с таким-то A> дескриптором процесса. Как видите, в обоих мыслимых случаях решение A> проблемы не представляет труда.
Но оно — не автоматическое, как тут кое-кто (не будем показывать пальцем,
все и так знают, что это Губанов) обещал.
A> (По крайней мере, мне так сейчас A> кажется. )
Чтоб так не казалось, имеет смысл подумать над вопросом — а откуда ядро
берет указатель на дескриптор соответствующего
приложения? И попытаться изобрести такую схему, которую невозможно
обмануть.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Собственно, к единому адресному пространству как таковому у меня, например, S>претензий не было. Я несогласен с другим утверждением — "GC и строгая S>типизация достаточны для реализации надежной ОС с единым адресным S>пространством, при это все модули, включая ядро, для рантайма равноценны. И S>дохлых указателей при этом не бывает". Именно это, как мне показалось, S>пытался утверждать Губанов.
Как мне кажется, я тоже утверждаю именно это.
Так что я согласен с Сергеем (если, конечно, мне не докажут, что это неправильная точка зрения).
Кстати, в приведенном мной примере единственная разница между модулями ядра и прикладными модулями состоит в том, что модули ядра загружаются однократно и не выгружаются. Т.е. это различие касается только динамического загрузчика. Во всем же остальном модули ядра и прикладные модули для рантайма равноценны.
S>...что на платформе х86 не так уж и здорово по причине этого самого S>адресного пространства ограниченности.
Та же Bluebottle поддерживает виртуальную память, насколько я понял из ее описания.
A>> Не требуется никакого переключения контекста для вызова системных A>> функций. Защита приложений друг от друга осуществляется единственно A>> надежностью статической и динамической типизации Оберона. S>Этого не достаточно. Поскольку раз некоторые объекты убиваются не по S>алгоритмам сборки мусора, могут образоваться висящие указатели.
Нет, в предложенном мной варианте все указатели обслуживаются одним единственным GC.
Просто системные дескрипторы "финализируются" (в случае необходимости) соответствующими процедурами ядра.
S>В принципе, я могу представить GC, который висящих указателей даже в такой ситуации не S>допустит и, скажем, их обнулит. Но это опять-таки перекладывание проблемы на S>программиста — он то может и не ожидать, что у него объекты, ссылки на S>которые он держит, пропадать начнут и вместо вызова их методов полетят S>исключения.
См. выше.
A>> Когда работа приложения завершается (в т.ч. по причине "плохого A>> поведения" ), ядро рассылает всем своим контейнерам broadcast-овое A>> сообщение: удалить все указатели на объекты, связанные с таким-то A>> дескриптором процесса. Как видите, в обоих мыслимых случаях решение A>> проблемы не представляет труда.
S>Но оно — не автоматическое, как тут кое-кто (не будем показывать пальцем, S>все и так знают, что это Губанов) обещал.
A>> (По крайней мере, мне так сейчас A>> кажется. )
S>Чтоб так не казалось, имеет смысл подумать над вопросом — а откуда ядро S>берет указатель на дескриптор соответствующего S> приложения? И попытаться изобрести такую схему, которую невозможно S>обмануть.
Я и пытаюсь это сделать.
Просто сделать это "одним махом" мне ума не хватает.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, prVovik, Вы писали:
V>Представляю себе сообщение информационного агентва: V>
Как выяснила коммиссия, взрыв на такой-то АЭС произошел из-за нелепой случайности. В самый неподходящий момент в крмпьютерной системе началась "сборка мусора", из-за которой не были вовремя обработаны датчики, информировавшие о критических параметрах работы атомного реактора. По предварителным оценкам, жертв...
Другой вариант гораздо более вероятен.
Как выяснила коммиссия, взрыв на такой-то АЭС произошел из-за нелепой случайности. Операционная система "убила" процесс, управляющий одним из критических блоков АЭС. Произошла ошибка Access Violation. Все ПО было написано на Си++.
По предварителным оценкам, жертв...
Страуструп и Торвальдс объявлены Интерполом в розыск.
V>Короче, ГЦ и СРВ — это вещи несовместимые.
На практике я не использую ГЦ в СРВ.
Так же как и free, delete и т.п.
В таких случаях "свободные" указатели не возвращаются в кучу, а "складируются" в стеках (например).
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Hello, AVC!
You wrote on Fri, 28 Jan 2005 13:03:28 GMT:
A> Как мне кажется, я тоже утверждаю именно это.
В том числе, что при выгрузке модулей без специальных мер не могут
образоваться дохлые указатели?
A> Так что я согласен с Сергеем (если, конечно, мне не докажут, что это A> неправильная точка зрения). Кстати, в приведенном мной примере A> единственная разница между модулями ядра и прикладными модулями A> состоит в том, что модули ядра загружаются однократно и не выгружаются. A> Т.е. это различие касается только динамического загрузчика. Во всем A> же остальном модули ядра и прикладные модули для рантайма A> равноценны.
Ну а я считаю, что одними перечисленными мерами не обойтись, понадобится еще
кое-чего. Как минимум — специальные средства межмодульного взаимодействия.
S>> ...что на платформе х86 не так уж и здорово по причине этого самого S>> адресного пространства ограниченности.
A> Та же Bluebottle поддерживает виртуальную память, насколько я понял из A> ее описания.
И что, она может быть больше 4Gb?
A>>> Не требуется никакого переключения контекста для вызова системных A>>> функций. Защита приложений друг от друга осуществляется единственно A>>> надежностью статической и динамической типизации Оберона. S>> Этого не достаточно. Поскольку раз некоторые объекты убиваются не по S>> алгоритмам сборки мусора, могут образоваться висящие указатели.
A> Нет, в предложенном мной варианте все указатели обслуживаются A> одним единственным GC.
Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули
выгружаем, но объекты из них остаются ?
A> Просто системные дескрипторы "финализируются" (в случае необходимости) A> соответствующими процедурами ядра.
Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...
S>> В принципе, я могу представить GC, который висящих указателей даже в S>> такой ситуации не допустит и, скажем, их обнулит. Но это опять-таки S>> перекладывание проблемы на программиста — он то может и не ожидать, что S>> у него объекты, ссылки на которые он держит, пропадать начнут и вместо S>> вызова их методов полетят исключения.
A> См. выше.
А то, что выше — это тоже перекладывание проблемы на программиста. Он,
кстати, может и не догадаться, что в данном конкретном случае дескриптор
нужен.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
)
