Здравствуйте, WolfHound, Вы писали:
WH>Вы меня не слышите. Дальнейшие попытки чего либо объяснить предприниматся не будут. Ибо бесполезно. WH>Прощайте.
Желаю всего наилучшего!
(От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Желаю всего наилучшего! :beer: AVC>(От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)
Похоже, обе стороны основательно устали на очередной войне. Можно перейти к дипломатическим методам: выработать общую терминологию (одни и те же вещи в ОС Оберон и Windows называются по-разному), цели создания Оберона, C# или чего там еще, ну и т. д. Только принимая во внимание все факторы, можно вести дискуццию в конструктивном тоне, не опускаясь до примитивного флейма. Тем более, что многие посты / реплики в последней войне выглядат гораздо солиднее и содержательнее как с одной, так и с другой стороны.
Я тоже извлек для себя пользу из нашего общения. Иначе не заходил бы сюда.
Счастливо! :beer:
Здравствуйте, Дарней, Вы писали:
AVC>>По мысли WolfHound, "граф будет жить вечно". (Как Дракула. ) AVC>>Но в Обероне все работает правильно. Д>Само собой, что и в CLR тоже — я не думал, что кому-то здесь этот факт неизвестен. Скорее всего, имелась в виду переменная, которая долгое время находится в области видимости (ну например локальная переменная функции-точки входа программы)
Я до сих пор не очень понимаю, что именно WolfHound имел в виду.
Кому "этот факт неизвестен" я тоже не знаю.
По крайней мере, один из моих предыдущих постов, утверждающий то же самое, Вы лично снабдили отрицательной оценкой.
Вот этот пост.
Дело в том, что указатель в Обероне может указывать только на объект, расположенный в куче и не может указывать ни на стековую, ни на статическую переменную.
Указатель получает свое значение только следующими путями:
1) NEW(p) — создать новый объект;
2) p := q; присвоить p значение другого валидного указателя q;
3) p := NIL; указатель никуда больше не указывает.
В начале указатель инициализирован NIL.
Т.е. указатель либо указывает на объект в куче, либо равен NIL.
И как же нам "зацепить" граф объектов за стек или статические переменные?
Я так и не понял тогда, в каком именно пункте Вы со мной не согласны.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Privalov, Вы писали:
P>Похоже, обе стороны основательно устали на очередной войне. Можно перейти к дипломатическим методам: выработать общую терминологию (одни и те же вещи в ОС Оберон и Windows называются по-разному), цели создания Оберона, C# или чего там еще, ну и т. д. Только принимая во внимание все факторы, можно вести дискуццию в конструктивном тоне, не опускаясь до примитивного флейма. Тем более, что многие посты / реплики в последней войне выглядат гораздо солиднее и содержательнее как с одной, так и с другой стороны.
P>Я тоже извлек для себя пользу из нашего общения. Иначе не заходил бы сюда. P>Счастливо!
Согласен!
Надо наконец-то перейти к более конструктивному обсуждению.
Как следствие, вероятно, постов станет меньше, но они будут содержательнее и продуманнее, и не будут носить "личного" характера.
Значит, пользы будет больше.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Желаю всего наилучшего! AVC>(От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)
WolfHound хотел сказать (если я правильно понял ), что разница между тем, забудем ли мы вызвать для неуправляемого указателя оператор delete, или забудем присвоить nil долгоживущему управляемому указателю в системе с ГЦ не принципиальна. В любом случае, память, которую можно было бы использовать для текущей задачи будет недоступна, и, следовательно, мы имеем утечку.
Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.
Здравствуйте, prVovik, Вы писали:
V>Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.
Проблема даже не в том, что объект может отжирать ресурсы. Проблема в том, что он может прийти в несогласованное состояние из-за ошибок в его коде и стать непригодным к применению. Если этот объект используется другими — значит, они тоже не смогут нормально работать.
Поэтому разделение на домены приложений — это есть единственно надежное решение, т.к. любые глобальные (точнее, статические) данные доступны только в текущем домене и другим помешать не смогут.
Ну а при наличии в системе неуправляемого кода (в любом виде) — разделение на процессы и зашита памяти тоже жизненно необходимы.
Если я не ошибаюсь, именно это долго и безуспешно пытаются донести до фанатов Оберона другие участники дискуссии.
Здравствуйте, prVovik, Вы писали:
V>WolfHound хотел сказать (если я правильно понял ), что разница между тем, забудем ли мы вызвать для неуправляемого указателя оператор delete, или забудем присвоить nil долгоживущему управляемому указателю в системе с ГЦ не принципиальна. В любом случае, память, которую можно было бы использовать для текущей задачи будет недоступна, и, следовательно, мы имеем утечку. V>Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.
По крайней мере, это — разумная мысль.
Если бы в ОС Оберон мы не могли "убить" "нашкодивший" процесс, то занятые им ресурсы не могли бы вернуться в систему.
Но, слава Богу, это не так. В Обероне можно "убить" процесс.
А иначе к чему бы привело возниковение первого же исключения в системе? (Скажем, при делении на ноль.)
Если такой процесс сам не перехватывает исключения, то за него это делает система. После чего данный конкретный процесс ликвидируется, ресурсы освобождаются, а система продолжает работать.
(Ядро же вообще неуязвимо, т.к. все его объекты либо недоступны снаружи (не экспортируются модулями ядра), либо доступны без возможности их изменения (экспортируются скрыто).)
Другая ситуация: бесконечный цикл.
LOOP END;
Эта ситуация кажется опасной для вариаций первоначальной ETH Oberon, потому что в ней многозадачность реализуется на базе единственного процесса.
Я проделывал такой эксперимент: писал модуль, содержащий команду с бесконечным циклом, и пытался "подвесить" систему. При нажатии Ctrl-Break (вместо вызова Task Manager'а в Windows) поток этой команды убивался, система работала, ресурсы возвращались (т.к. Ctrl-Break вызывала исключение.)
Не блестяще, конечно, но первоначальная версия ETH Oberon предназначалась для однопользовательской рабочей станции. Так что такое поведение вполне было приемлимо. (Windows в те годы преспокойно зависала.)
И надо помнить, что сейчас существует варианты Оберона с "настоящей" многозадачностью.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Дарней, Вы писали:
Д>Я бы сказал немного по другому — в определенной (очень узкой) области такая замена приемлема.
Я уже как то очерчивал эту область. Дело не в ресурсах. ОС без защиты памяти допустимы в том случае если мы контролируем весь софт, запускаемый под этой осью. Скажем для архитектуры PocketPC такая ось не годится, а для какого нибудь телефона вполне, хотя ресурсы и там и там сопоставимые.
AndrewJD пишет:
>>> Вот корректный код: >>>PROCEDURE Do (N: INTEGER); >>>VAR list: List; i: INTEGER; >>>BEGIN >>> NEW(list); >>> FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END >>>END Do; >>> >>> > C>И пусть N=2^64. > C>Будет точно то же самое — утечка памяти до ее полного переполнения. > Ммм. А где собственно утечка?
Мы имеем семантический мусор в переменной list — ее содержимое никогда
не будет использовано, но существующие ссылки не дают этот мусор удалить.
Здравствуйте, Дарней, Вы писали:
Д>Если я не ошибаюсь, именно это долго и безуспешно пытаются донести до фанатов Оберона другие участники дискуссии.
Это, IMHO, действительно, центральный вопрос.
Собственно говоря, единственный.
Остальные претензии к Оберону, скорее, надуманы. Их, почему-то, больше всего и "мусолят".
Но почему же "долго и безуспешно"?
См. например: http://www.rsdn.ru/Forum/Message.aspx?mid=1001716&only=1
Опять же Вы лично выражали несогласие с моей точкой зрения. Запамятовали?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
C> И что? С каких это пор бесконечный цикл стал ошибкой?
Бесконечный цикл в котором выделяется память и назад никогда не отдается безусловно является ошибкой, просто согласно здравому смыслу — объем памяти конечен, следовательно рано или позндно вся память будет исчерпана.
Кстати, при чем тут наличие или отсутсвие GC Вы так и не объяснили.
Hello, Сергей!
You wrote on Wed, 26 Jan 2005 14:41:58 GMT:
СГ> Бесконечный цикл в котором выделяется память и назад никогда не СГ> отдается безусловно является ошибкой, просто согласно здравому смыслу - СГ> объем памяти конечен, следовательно рано или позндно вся память будет СГ> исчерпана.
Кстати, пусть это будет ошибкой. Ну что с ней дальше делать — всю систему
ронять?
СГ> Кстати, при чем тут наличие или отсутсвие GC Вы так и не объяснили.
Не знаю, что имел в виду Cyberax, но лично мне, например, непонятно, что
должен делать в таком случае GC (или кто там будет освобождать память при
убиении ошибочного модуля), при условии, что, как вы ранее заявляли, "... то
необходимость в создании множества виртуальных адресных пространств (для
безопасности) больше не существует — достаточно одного единого на всю
систему адресного пространства, а безопасность гарантируется языком
программирования, рантайм проверками индексов массивов, контролем приведения
типов."
В случае раздельных адресных пространств все просто — отстреливаем дохлую
задачу и освобождаем всю принадлежащую ей память. Что делать в случае
единого адресного пространства, когда вся надежда только на GC?
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>В случае раздельных адресных пространств все просто — отстреливаем дохлую S>задачу и освобождаем всю принадлежащую ей память. Что делать в случае S>единого адресного пространства, когда вся надежда только на GC?
Вот ума не приложу — какая разница сколько у Вас адресных пространств?
Убей более не нужный объект — память освободиться сама (за счет того самого GC).
Hello, Сергей!
You wrote on Wed, 26 Jan 2005 15:11:49 GMT:
S>> В случае раздельных адресных пространств все просто — отстреливаем S>> дохлую задачу и освобождаем всю принадлежащую ей память. Что делать в S>> случае единого адресного пространства, когда вся надежда только на GC?
СГ> Вот ума не приложу — какая разница сколько у Вас адресных СГ> пространств? Убей более не нужный объект — память освободиться сама СГ> (за счет того самого GC).
Он не ненужный, он с ошибкой — взбесился и начал немерянно отжирать память.
И другие объекты имеют указатели, показывающие на этот объект и его части.
Что произойдет с ними, если убить дефектный объект?
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
C>Мы имеем семантический мусор в переменной list — ее содержимое никогда C>не будет использовано, но существующие ссылки не дают этот мусор удалить.
Это уже проблема оптимизатора, который не удалил код который ничего не делает. После выхода из блока(в данном случае функции) все почистится. Где утечка?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
AndrewJD пишет:
> C>Мы имеем семантический мусор в переменной list — ее содержимое никогда > C>не будет использовано, но существующие ссылки не дают этот мусор > удалить. > Это уже проблема оптимизатора, который не удалил код который ничего не > делает.
Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ
программы. В данном куске кода все сразу видно, но в реальности все
может быть намного сложнее.
> После выхода из блока(в данном случае функции) все почистится. Где > утечка?
А мы НИКОГДА не выходим из блока. Можно сделать переменную list
статической — результат будет ровно тем же.
Здравствуйте, Cyberax, Вы писали:
C>Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ C>программы. В данном куске кода все сразу видно, но в реальности все C>может быть намного сложнее.
Только причем здесь GC?
Чем этот код принципиально отличается от
char* p = new char[2000000000];
//здесь что-то делаемdelete[] p;
C>А мы НИКОГДА не выходим из блока. Можно сделать переменную list C>статической — результат будет ровно тем же.
Все равно ничего не понимаю .
Ровно с таким же успехом мы могли попытаться поднять в память 4 гигабайтный xml и попытаться распарсить его в DOM.
Т.е. это будет не мусор, а 8 гиг полезных данных.
Какое это отношение имеет к защите памяти, GC, и раздельным адресным пространствам?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
AndrewJD пишет:
> C>Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ > C>программы. В данном куске кода все сразу видно, но в реальности все > C>может быть намного сложнее. > Только причем здесь GC? > Чем этот код принципиально отличается от > >char* p = new char[2000000000]; > >//здесь что-то делаем > >delete[] p; > >
Принципиально ничем не отличается.
> C>А мы НИКОГДА не выходим из блока. Можно сделать переменную list > C>статической — результат будет ровно тем же. > Все равно ничего не понимаю . > Ровно с таким же успехом мы могли попытаться поднять в память 4 > гигабайтный xml и попытаться распарсить его в DOM. > Т.е. это будет не мусор, а 8 гиг полезных данных. > Какое это отношение имеет к защите памяти, GC, и раздельным адресным > пространствам?
Я привел пример кода, который вызовет ошибочную ситуацию в системе. В
обычных ОСах система может просто прибить процесс, который эту ситуацию
вызвал (у всех процессов — разные адресные пространства), но в ОберонОС
этого сделать нельзя — так как нельзя автоматически определить какие
объекты являются мусорными. Прибивать произвольные объекты тоже нельзя —
нарушится ссылочная целостность.
)
.