MODULE  sgTest003;
IMPORT  StdLog;

PROCEDURE   Проверка*;
  TYPE A = POINTER TO ARRAY 10000000 OF INTEGER;
  VAR a: A;
BEGIN
  StdLog.String(" Создаю "); StdLog.Ln();
  NEW(a);    (* В этом месте я вижу через Windows Task Manager  как BlackBox забрал
память*)
  StdLog.String(" Выхожу из области видимости "); StdLog.Ln();
  a := NIL; (* Я думаю, что сборщик мусора должен активизироваться в этом месте *)
END Do;
(* В этом месте я ожидаю, что BlackBox отдаст память обратно в распоряжение Windows
XP*)

BEGIN
END  sgTest003.

(Коммандер)sgTest003.Проверка

Ответ на »сообщение 86« (Андрей Хохлов)
___________________________

Еще вопрос. В КП (и O2?) метод может привязываться к записи и указателю на запись. И это можно смешивать:
Смысл в том, что метод, привязанный к записи, можно вызывать и для статических, и для динамических экземпляров. Метод, привязанный к указателю, можно вызывать только для динамических экземпляров. И такие методы действительно можно сочетать для одного типа. Принципиальная разница, из-за которой может потребоваться это различать в том, что в Обероне не бывает указателей на статические экземпляры (только ссылки через параметры). Поэтому, например, динамический экземпляр можно подцепить в список, статический - нет.

И как-то уж очень некрасиво сделали модификаторы - запятая перед NEW совсем не к месту.
Так уж повелось в Паскалях. В Турбо и Object. Ничего особо некрасивого, по-моему, нет. Согласуется с правилами русского языка, кстати - определение, стоящее после подлежащего и отделенное длинной фразой. "Объект с именем А, новый"

Еще вопрос. В КП (и O2?) метод может привязываться к записи и указателю на запись. И это можно смешивать:

TYPE
  T = EXTENSIBLE RECORD
    ...
  END;

  P = POINTER TO T;

PROCEDURE*(IN/VAR t: T) P1(), NEW, EXTENSIBLE;
  BEGIN
    StdLog.String ("T1.P1");
    StdLog.Ln()
  END P1;

PROCEDURE*(p: P) P2(), NEW, EXTENSIBLE;
  BEGIN
    StdLog.String ("T1.P2");
    StdLog.Ln()
  END P2;

Какой в этом смысл?

И как-то уж очень некрасиво сделали модификаторы - запятая перед NEW совсем не к месту.

Ответ на »сообщение 82« (AVC)
___________________________

Ответ на »сообщение 81« (Руслан Богатырев)
___________________________
Я и хочу исследовать вопрос: а можно ли гарантировать безопасность выгрузки модулей?
Первоначально этот вопрос для меня возник, когда Сергей Губанов высказал мысль (я, возможно, ее искажаю; поэтому заранее извиняюсь перед Сергеем), что модульной можно называть только такую систему, где можно подменить модуль на лету.

Имелось в виду, что подмену осуществляет сама прикладная система, т.е. принятие решения о выгрузке и "отмонтирование" заложено в саму ее логику. Среда выполнения всего лишь предоставляет техническую возможность для этого.

Однако идея "адаптивной модульности", когда подмена происходит прозрачно для самой системы - штука интересная. Здесь потребуется, чтобы различные реализации были совместимы "по состоянию" и могли выгружаться/загружаться в перманентный поток. Тогда для замены модуля на лету проделываем: ModuleA.Externalize(memoryStore); Unload(ModuleA); Load(ModuleB); ModuleB.Internalize(memoryStore).
Однако тут проблема не только в процедурных переменных. Экспортированные сущности могут иметь скрытые поля, содержащие указатели на экземпляры неэкспортированных сущностей, которые есть, например, в модуле A, но нет в модуле B. Так что вопрос очень сложный... Тут, видимо, потребуется замена указателей какими-то интеллектуальными прокси-объектами...

Ответ на »сообщение 82« (AVC)
___________________________

Я и хочу исследовать вопрос: а можно ли гарантировать безопасность выгрузки модулей?

Давайте для удобства все же делить модули на языковые (единица компиляции) и операционные (единица загрузки/исполнения).

Каждый модуль (в понимании Оберона/КП) заключает внутри себя некоторые сущности. Эти сущности двух видов: изменяемые (в ходе выполнения; переменные/объекты) и неизменяемые (константы, типы, процедуры). Модули -- это капсулы, но они связаны друг с другом -- прямо или косвенно. Т.е. существуют межмодульные связи как явные (экспорт/импорт), так и неявные (через ресурсы, включая память).

Если ставится задача обеспечения безопасной загрузки/выгрузки операционных модулей, то необходимо гарантировать:
1. Удаление (выгрузку) модуля, у которого нет межмодульных связей (явных и неявных).
2. Подмену (выгрузку/загрузку) модуля, у которого существуют межмодульные связи.

Как мы выяснили, дело осложняется возможным наличием модулей-"невидимок" (стэлз-модулей). Это, кстати, порождает, нетривиальные циклические зависимости (граф с циклами). Нельзя забывать и о необходимости отслеживания текущего состояния зависимых модулей (при подмене на лету).

Задача имеет аналогии со сборкой мусора (памяти). При этом усугубляется задачей подмены. При подмене нужно каким-то образом гарантировать соблюдение контракта/протокола работы зависимых модулей с учетом состояния их изменяемых сущностей.

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

Ответ на »сообщение 82« (AVC)
___________________________

Опять же возвращаюсь мыслью к введению своеобразного аналога сборки для Оберона.

Ответ на »сообщение 81« (Руслан Богатырев)
___________________________


Как выгружать/загружать этот модуль-диспетчер R будем? Экспорта-импорта нет. Значит, помимо запретов процедурных переменных нужна, оказывается, и грамотная финализация? А ведь хотелось бы подменить модуль на лету, т.е. не финализировать, а "приморозить"? Так как же насчет безопасности выгрузки?


Я и хочу исследовать вопрос: а можно ли гарантировать безопасность выгрузки модулей?
Первоначально этот вопрос для меня возник, когда Сергей Губанов высказал мысль (я, возможно, ее искажаю; поэтому заранее извиняюсь перед Сергеем), что модульной можно называть только такую систему, где можно подменить модуль на лету.
Если динамическая загрузка по требованию у меня проблем в понимании не вызвала, то с выгрузкой оказалось гораздо труднее.
Ведь "завязки" между модулями возникают не только через списки импорта, но и через объектные связи (указатели и процедурные переменные), и иными косвенными способами (Вы только что привели хороший пример).
Казалось бы, на выгрузке модулей можно было бы "поставить крест" и успокоиться, но меня беспокоит вопрос: а как тогда будет очищаться память в Оберон-системе, где нет отдельных процессов?
Ведь в конце концов, загруженные модули могут заполнить всю память, а выгрузка опасна.
Что делать? :)

Ответ на »сообщение 80« (AVC)
___________________________

Доведя мысль до спорной, скажу, что для того, чтобы добиться безопасной выгрузки модулей, возможно, следует отказаться от процедурных переменных.

Простой пример. Есть модуль R, в котором осуществляется заведение (диспетчеризация) некоторых ресурсов (для простоты -- файлы). Эти ресурсы сдаются им в аренду другим модулям (M1, M2 и т.п.). Процесс передачи в аренду может быть различным -- вплоть до опосредованного (т.е. "именное связывание") через некоторый файл (файл m1.ok создан -- значит, можно пользовать (читать/писать) те файлы, чьи имена внутри него указаны).

Как выгружать/загружать этот модуль-диспетчер R будем? Экспорта-импорта нет. Значит, помимо запретов процедурных переменных нужна, оказывается, и грамотная финализация? А ведь хотелось бы подменить модуль на лету, т.е. не финализировать, а "приморозить"? Так как же насчет безопасности выгрузки?

В роли ресурсов, за которые будут "биться" модули (классы, потоки/процессы), могут выступать, конечно, не только файлы.

Ответ на »сообщение 79« (AVC)
___________________________

Доведя мысль до спорной, скажу, что для того, чтобы добиться безопасной выгрузки модулей, возможно, следует отказаться от процедурных переменных.
(Это скорее вопрос, чем утверждение. Напомню, что этот вопрос всплыл в контексте обсуждения того, насколько важна для Оберона выгрузка модулей.)

Кажется, авторы КП на это намекали.
ИМХО, достаточно полное представление о языке (его достоинстве и противоречиях) можно получить только наблюдая его эволюцию.
Поэтому для изучения Оберона наличие разных диалектов и даже отдельных языков семейства дает богатую пищу для размышлений.
(Но затрудняет миграцию исходных кодов -- вопрос, который поднимал здесь Руслан Богатырев.)

Ответ на »сообщение 78« (AVC)
___________________________


В принципе согласен, что сборщик мусора мог бы получить такую информацию из дескриптора типа.
Но это, опять же, только в О-2 и КП...

М-да, высказался...
Опять же получается, что я имею в виду только методы. :)

Ответ на »сообщение 77« (Trurl)
___________________________


Адреса процедур также хранятся в местах, доступных сборщику мусора.

Я исходил из того, что сборщик мусора имеет дело только с указателями и объектами в куче, а процедурные переменные (даром, что тоже адреса :) ) (обычными) указателями не являются.
В принципе согласен, что сборщик мусора мог бы получить такую информацию из дескриптора типа.
Но это, опять же, только в О-2 и КП...