Здравствуйте, DJ KARIES, Вы писали:

DK>Здравствуйте, Cyberax, Вы писали:

C>>А что будет у нас в Обероне, если прибить модуль System, например?
DK>Таки отвечу вопросом на вопрос.
DK>Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе?
DK>Ибо некошерно.

Дело не в этом. Модуль SYSTEM на самом деле является псевдо модулем интегрированным в компилятор. Выгрузить его нельзя просто потому что его реально не существует. То есть модуль SYSTEM даже не является частью операционной системы.

---

Вместо модуля SYSTEM лучше рассмотреть модуль Kernel.

Например, в БлэкБоксе именно в модуле Kernel определена процедура выгрузки модулей:

PROCEDURE UnloadMod (mod: Kernel.Module);

Я пытался с помощью нее выгрузить сам модуль Kernel, так ничего не вышло, вызов был просто проигнорирован.

Здравствуйте, Sergey, Вы писали:

S>В том числе, что при выгрузке модулей без специальных мер не могут
S>образоваться дохлые указатели?
"Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не образуются на что попало. Т.к. во-превых: указатель на объект другого модуля — это не просто указатель, во-вторых: всё остальное является копиями. Главное, что дохлый указатель — это правильный указатель, т.е. null или ссылка на InvalidObject, а не мусор.

A>> Так что я согласен с Сергеем (если, конечно, мне не докажут, что это
A>> неправильная точка зрения). Кстати, в приведенном мной примере
A>> единственная разница между модулями ядра и прикладными модулями
A>> состоит в том, что модули ядра загружаются однократно и не выгружаются.
A>> Т.е. это различие касается только динамического загрузчика. Во всем
A>> же остальном модули ядра и прикладные модули для рантайма
A>> равноценны.

S>Ну а я считаю, что одними перечисленными мерами не обойтись, понадобится еще
S>кое-чего. Как минимум — специальные средства межмодульного взаимодействия.
Би зус лов на. Так же как недостаточно одного лишь GDTR.

S>И что, она может быть больше 4Gb?
На самом деле, если ты всегда обращаешься по управляемому указателю и GC один на всех, то памяти может сколько угодно.

S>Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули
S>выгружаем, но объекты из них остаются ?
Как я понимаю модуль — это единица кода. Данные тут ваще не при чём. Вы до сих пор не воткнули , что модуль — это не аналог процесса. Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

A>> Просто системные дескрипторы "финализируются" (в случае необходимости)
A>> соответствующими процедурами ядра.
S>Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...
А то.

S>>> В принципе, я могу представить GC, который висящих указателей даже в
S>>> такой ситуации не допустит и, скажем, их обнулит. Но это опять-таки
S>>> перекладывание проблемы на программиста — он то может и не ожидать, что
S>>> у него объекты, ссылки на которые он держит, пропадать начнут и вместо
S>>> вызова их методов полетят исключения.

A>> См. выше.
S>А то, что выше — это тоже перекладывание проблемы на программиста. Он,
S>кстати, может и не догадаться, что в данном конкретном случае дескриптор
S>нужен.
Обычно C++ гуру называют таких программистов безнадежными, жертва аборта, ошибка ДНК. Так что можно расслабиться.

Hello, Poudy!
You wrote on Fri, 28 Jan 2005 13:55:40 GMT:

S>> В том числе, что при выгрузке модулей без специальных мер не могут
S>> образоваться дохлые указатели?
P> "Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не
P> образуются на что попало. Т.к. во-превых: указатель на объект другого
P> модуля — это не просто указатель, во-вторых: всё остальное является
P> копиями. Главное, что дохлый указатель — это правильный
P> указатель, т.е. null или ссылка на InvalidObject, а не мусор.

Во-во, что я пытаюсь объяснить. "Дохлые указатели" — вполне нормально, но
они кардинально усложняют ситуацию.

S>> И что, она может быть больше 4Gb?
P> На самом деле, если ты всегда обращаешься по управляемому указателю и GC
P> один на всех, то памяти может сколько угодно.

Да, про это я не подумал.

S>> Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули
S>> выгружаем, но объекты из них остаются ?
P> Как я понимаю модуль — это единица кода. Данные тут ваще не при чём.
P> Вы до сих пор не воткнули , что модуль — это не аналог процесса.
P> Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код и
данные этой задачи. Получатся дохлые указатели. Так понятней?

A>>> Просто системные дескрипторы "финализируются" (в случае необходимости)
A>>> соответствующими процедурами ядра.
S>> Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...
P> А то.

Вот Губанову это и объясни

P> Обычно C++ гуру называют таких программистов безнадежными, жертва
P> аборта, ошибка ДНК. Так что можно расслабиться.

Нельзя расслабится. Такая ситуация легко может возникнуть у самого что ни на
есть гуру при не слишком тщательном рефакторинге. Это должно быть запрещено
автоматически, на уровне языка или на уровне операционки.

With best regards, Sergey.

Здравствуйте, Cyberax, Вы писали:

C>Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x
C>оверхедом.
Ваше "серьезно говорю" можно понимать как:
1) Доказано, что realtime-GC требует >= 2x оверхеда.
2) В настоящее время не существует realtime-GC с < 2x оверхедом.
3) Вам лично такие системы неизвестны.
Я могу безусловно согласиться только с последним вариантом.

Трурль пишет:

> C>Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x
> C>оверхедом.
> Ваше "серьезно говорю" можно понимать как:
> 1) Доказано, что realtime-GC требует >= 2x оверхеда.
> 2) В настоящее время не существует realtime-GC с < 2x оверхедом.

Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.
А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который возможен минимум с 2x
оверхедом".

СГ> Я пытался с помощью нее выгрузить сам модуль Kernel, так ничего не вышло, вызов был просто проигнорирован.

Извиняюсь, запарил. Не только его нельзя выгрузить, а вообще никакой модуль нельзя выгрузить пока у него есть клиенты, т.е. пока его кто-то импортирует. Выгружать модули надо начиная с листьев дерева импорта модулей (с тех, которые уже никто более не импортирует).

Трурль пишет:

> C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.
> А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который
> возможен минимум с 2x
> оверхедом".

Запускающийся независимо от желаний приложения, и работающий сколько ему
захочется...

Синхронный GC запускается явно по требованию.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Sergey, Вы писали:

S>>> В том числе, что при выгрузке модулей без специальных мер не могут
S>>> образоваться дохлые указатели?
P>> "Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не
P>> образуются на что попало. Т.к. во-превых: указатель на объект другого
P>> модуля — это не просто указатель, во-вторых: всё остальное является
P>> копиями. Главное, что дохлый указатель — это правильный
P>> указатель, т.е. null или ссылка на InvalidObject, а не мусор.

S>Во-во, что я пытаюсь объяснить. "Дохлые указатели" — вполне нормально, но
S>они кардинально усложняют ситуацию.
Да ничего не кардинально. Я почти уверен, что в BlueBottle используется механизм similar to AppDomain.
Тебе так мешают жить указатели на удаленные объекты? (слово-то какое Широка семантика русского языка — объект, находящийся на другой машине есть удаленный объект )

S>>> Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули
S>>> выгружаем, но объекты из них остаются ?
P>> Как я понимаю модуль — это единица кода. Данные тут ваще не при чём.
P>> Вы до сих пор не воткнули , что модуль — это не аналог процесса.
P>> Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

S>Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код и
S>данные этой задачи. Получатся дохлые указатели. Так понятней?
Я понимаю это так: модуль при старте может создавать активный объект — это и есть объект собственно модуля. Во всех других модулях данный модуль виден тока как код. Для каждого модуля существуют копии всех статических переменных других модулей (пусть Губанов поправит, если не так). Соотв если есть модульи А и Б, и я создал в активном объекте модуля А простой объект модуля Б, то этот объект принадлежит модулю А, также как и все копии статических переменных модуля Б. В этом смысле модуль упасть не может принципиально. Грохаются только активные объекты и все принадлежащие им объекты. Если в грохаемом объекте есть ссылка на объекты принадлежащие активным объектам других модулей (а не принадлежащие классам, определенным в других модулях), то такие объекты остаются живы и требуют отдельной обработки (как в слечае с хендлами, вероятно). Но все объекты данного активного объекта модуля грохаются. Вощем, смотри AppDomain, Remoting и т.д.

P>> Обычно C++ гуру называют таких программистов безнадежными, жертва
P>> аборта, ошибка ДНК. Так что можно расслабиться.

S>Нельзя расслабится. Такая ситуация легко может возникнуть у самого что ни на
S>есть гуру при не слишком тщательном рефакторинге. Это должно быть запрещено
S>автоматически, на уровне языка или на уровне операционки.
Та это невозможно. Что возможно (теоретически), так это доказать, что такое невозможно . На самом деле CannotAccessDisposedObjectException — это и есть решение "на уровне операционки".

S>With best regards, Sergey.

Hello, Poudy!
You wrote on Fri, 28 Jan 2005 14:47:20 GMT:

S>> Во-во, что я пытаюсь объяснить. "Дохлые указатели" — вполне нормально,
S>> но они кардинально усложняют ситуацию.
P> Да ничего не кардинально.
Ну это кому как.

P> Я почти уверен, что в BlueBottle используется механизм similar to
P> AppDomain. Тебе так мешают жить указатели на удаленные объекты?
P> (слово-то какое
Лично мне — очень. Я сейчас как раз нечто подобное пишу, только на плюсах

S>> Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код
S>> и данные этой задачи. Получатся дохлые указатели. Так понятней?
P> Я понимаю это так: модуль при старте может создавать активный объект -
P> это и есть объект собственно модуля. Во всех других модулях данный
P> модуль виден тока как код. Для каждого модуля существуют копии всех
P> статических переменных других модулей (пусть Губанов поправит, если не
P> так). Соотв если есть модульи А и Б, и я создал в активном объекте
P> модуля А простой объект модуля Б, то этот объект принадлежит модулю А,
P> также как и все копии статических переменных модуля Б. В этом смысле
P> модуль упасть не может принципиально.

Ладно, буду говорить "Активный Объект"

P> Грохаются только активные объекты и все принадлежащие им объекты.
P> Если в грохаемом объекте есть ссылка на объекты принадлежащие
P> активным объектам других модулей (а не принадлежащие классам,
P> определенным в других модулях), то такие объекты остаются живы и требуют
P> отдельной обработки (как в слечае с хендлами, вероятно).

Гораздо важнее вопрос, что делать с объектами, ссылающимися на убиваемый
объект.

S>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого что
S>> ни на есть гуру при не слишком тщательном рефакторинге. Это должно быть
S>> запрещено автоматически, на уровне языка или на уровне операционки.
P> Та это невозможно. Что возможно (теоретически), так это доказать, что
P> такое невозможно .

Да ну. Запретить объектам из одной задачи ссылаться на объекты другой таким
же образом, что и на объекты своей задачи — невозможно? Ну докажи попробуй.

With best regards, Sergey.

Здравствуйте, Sergey, Вы писали:

S>>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого что
S>>> ни на есть гуру при не слишком тщательном рефакторинге. Это должно быть
S>>> запрещено автоматически, на уровне языка или на уровне операционки.
P>> Та это невозможно. Что возможно (теоретически), так это доказать, что
P>> такое невозможно .

S>Да ну. Запретить объектам из одной задачи ссылаться на объекты другой таким
S>же образом, что и на объекты своей задачи — невозможно? Ну докажи попробуй.
Весь мир идет к тому, чтобы не делать различий, а ты хочешь всё вернуть .
Я понимаю всю головную боль, но пока что такие вещи решаются написанием оберток
Да, вероятно было было бы неплохо иметь в удаленной ссылке автоматом событие Disconnected и т.д.

А невозможно сделать так, чтобы объект был не твой и удаляемый, но всё работало само как надо.

Здравствуйте, Poudy, Вы писали:

P> Я понимаю это так: модуль при старте может создавать активный объект — это и есть объект собственно модуля.

В принципе он может создать не один а сколько угодно активных объектов...

P> Для каждого модуля существуют копии всех статических переменных других модулей (пусть Губанов поправит, если не так).

Копий нет:

MODULE M
  VAR K: INTEGER;
END M.

переменная M.K — одна на всю систему.

Здравствуйте, Cyberax, Вы писали:

C>Трурль пишет:

>> C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.
>> А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который
>> возможен минимум с 2x
>> оверхедом".

C>Запускающийся независимо от желаний приложения, и работающий сколько ему
C>захочется...

C>Синхронный GC запускается явно по требованию.


Вопрос.
Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

Ведь, по идее, если мы не вызываем NEW(p), то зачем GC напрягаться-то(???), он может спокойно курить... а вот как только мы вызвали NEW(p), так он сразу — если есть память, то мгновенно ее возвращает, а если нет, то тут он напрягается, трудится-работает убирает мусор, как только уберет сколько затребовали, возвращает ее и дальше курит...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вопрос.
СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

Сергей, а ты знаешь как Garbage Collector переводится и что делает?

Hello, Poudy!
You wrote on Fri, 28 Jan 2005 15:49:26 GMT:

S>>>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого
S>>>> что ни на есть гуру при не слишком тщательном рефакторинге. Это
S>>>> должно быть запрещено автоматически, на уровне языка или на уровне
S>>>> операционки.
P>>> Та это невозможно. Что возможно (теоретически), так это доказать, что
P>>> такое невозможно .

S>> Да ну. Запретить объектам из одной задачи ссылаться на объекты другой
S>> таким же образом, что и на объекты своей задачи — невозможно? Ну докажи
S>> попробуй.
P> Весь мир идет к тому, чтобы не делать различий, а ты хочешь всё вернуть
P> .

Отучаемся говорить за весь мир Программисту приходится знать, может метод
объекта кинуть исключение или не может. Писать код в условиях, когда любой
метод любого объекта может кинуть исключение сложнее, чем когда исключений
нет. Соответственно, от общности в данном конкретном случае помимо пользы
есть и вред.

P> А невозможно сделать так, чтобы объект был не твой и удаляемый, но всё
P> работало само как надо.

Разумеется.

With best regards, Sergey.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Вопрос.
СГ>>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

К>Сергей, а ты знаешь как Garbage Collector переводится и что делает?

Ну, я имел ввиду весь менеджер памяти неотделимой частью которого является GC.
NEW(p) — запускает его, стало быть, в некотором смысле, может рассматриваться как завуалированный вызов GC если он вдруг нужен. Если мы долгое время не вызываем NEW(p), то GC преспокойно может это самое долгое время ничего не делать. Зачем напрягаться понапрасну? Так или нет?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>>Вопрос.
СГ>>>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

К>>Сергей, а ты знаешь как Garbage Collector переводится и что делает?

СГ>Ну, я имел ввиду весь менеджер памяти неотделимой частью которого является GC.

Сборщик мусора является лишь частью менеджера памяти и соответственно остальные части менеджера сборщиком не являются, так что не надо тут софизмы изрекать, плиз

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вопрос.
СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

Да, но только в случае однозадачной системы.
Еще придется располагать временнЫми гарантиями работы ГЦ

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Системный список указателей на пользовательские объекты можно написать так, чтобы он автоматически забывал о плохом объекте, псевдокод:

Можно. А можно и не написать. Разговор-то идет о средствах, обеспечивающих безопасность системы автоматически, вне зависимости от криворукости программиста. А в том, что теоретически можно написать идеальную программу я, конечно, не сомневаюсь. Вот только практика и теория — обычно разные вещи...

Здравствуйте, Сергей Губанов, Вы писали:

>>> возможен минимум с 2x
>>> оверхедом".
C>>Запускающийся независимо от желаний приложения, и работающий сколько ему
C>>захочется...
C>>Синхронный GC запускается явно по требованию.
СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?
СГ>Ведь, по идее, если мы не вызываем NEW(p), то зачем GC напрягаться-то(???), он может спокойно курить... а вот как только мы вызвали NEW(p), так он сразу — если есть память, то мгновенно ее возвращает, а если нет, то тут он напрягается, трудится-работает убирает мусор, как только уберет сколько затребовали, возвращает ее и дальше курит...

Да, но в системе реального времени в дело вступает еще один фактор: достаточно ли у GC времени на то, чтоб завершить свою работу. И память должна выделиться независимо от того, достаточно или недостаточно. Стало быть для гарантированного выделения N байт памяти эти N байт должны быть уже свободны в системе, а GC при вызове должен трудиться над очисткой уже следующих N байт для сделующего гарантированного выделения памяти. Думаю Cyberax именно это имел в виду, когда говорил, что необходим 2x overhead.