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

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

Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?

ЗЫ Просьба не цепляться к словам, если не нравится "не-обероновский" термин "приложение" можем считать его "активным объекто типа TApplication" или еще чем-то, главное чтоб сохранилась суть.

Сергей Губанов пишет:

> P> Для каждого модуля существуют копии всех статических переменных
> других модулей (пусть Губанов поправит, если не так).
> Копий нет:
>
>MODULE M
> VAR K: INTEGER;
>END M.
>
> переменная M.K — одна на всю систему.

То есть, если пользователь Вася загрузит модуль "Photoshop", то
пользователь Петя уже не сможет его загрузить?

Или Оберон — исключительно однопользовательский?

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

Сергей Губанов пишет:

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

Конечно, можно. Оно, кстати, часто так и делается (оператор new —
замечательный safepoint для GC).

Вот только в realtime-системах нужно обеспечить ЖЕСТКУЮ гарантию на
время исполнения new. И вариант "от секунды до часа, как Бог пошлет" —
не подходит.

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

Именно ЭТО в realtime-системах и неприемлимо. По определению.

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

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

P>Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?

P>ЗЫ Просьба не цепляться к словам, если не нравится "не-обероновский" термин "приложение" можем считать его "активным объекто типа TApplication" или еще чем-то, главное чтоб сохранилась суть.
И всё равно есть постоянная подмена понятий и путаница в словах. Сначала ты говоришь "Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение?", а потом "что произойдет с остальными N-1 приложениями, использующими данный модуль". Какой модуль? А? Или модуль приложения? С модулем А ничего не произойдет, потому что: а — это код, б — его объекты ни в чем не виноваты. С другими приложениями, полагающимися на приложение TApplication произойдет то же, что и с аськой при падеже сервера: всё зависит от самих асек; как они написаны были, так и будет. Всё-таки остается непонимание вещей, хоть ты и говоришь "главное чтоб сохранилась суть".

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

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

Да, вред есть. Да, сложно писать, когда всё может кинуть исключение. Но в данном случае я не понимаю:
а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие могут находиться удаленно и пр.?
б — неужто приватные Hashtable могут кидать исключения и это составляет проблему?
в — для удаленных объектов существуют (должны, по крайней мере) методы вклинивания в вызовы. На крайняк можно написать обертку.
г — все глобальный проблемы надежности подобных штук решаются только повышением надежности. Как много программ на Java или C# закладываются на какой-нибудь NotEnougthMemoryException или UndefinedBehaviorException при new ?

Или ты хочешь сделать какую-нибудь систему, вроде GC или проверки выхода за границы массива, но только для распределенной работы? Хмм.. Это потянет на докторскую. Быть может даже в этом есть резон. Быть может даже трудов 50 на это дело написано.

Hello, Poudy!
You wrote on Sat, 29 Jan 2005 12:15:59 GMT:

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

P> Да, вред есть. Да, сложно писать, когда всё может кинуть исключение.
P> Но в данном случае я не понимаю:

P> а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие
P> могут находиться удаленно и пр.?

При чем здесь я?
Программист на Обероне может и не знать — компонентная среда и все такое.

P>
б — неужто приватные Hashtable могут
P> кидать исключения и это составляет проблему?

При чем здесь Hashtable?

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

Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не читаю.

P>
г — все глобальный проблемы надежности
P> подобных штук решаются только повышением надежности.

Гы

P>
Как много программ
P> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
P> или UndefinedBehaviorException при new ?

Почем я знаю? Лично мне такую возможность часто приходится учитывать.

P> Или ты хочешь сделать какую-нибудь систему, вроде GC или проверки выхода
P> за границы массива, но только для распределенной работы?

Я? Нет. У меня простой RPC с хэндлами. Без GC.

With best regards, Sergey.

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

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

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

P>Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?

Зависит от системы.
Могу сказать как обстоят дела в BlackBox, как с остальными системами — надо обращаться к их документации.

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

Есть такое понятие как команда. Мы просим БлэкБокс выполнить команду "A.DoEndlessLoop" вот так вот именно в виде текстовой строки передаем имя модуля и имя процедуры.

Аналогично в UNIX:

./ADoEndlessLoop.out

или в DOS/Windows:

ADoEndlessLoop.exe

Система загружает в память модуль А (если он еще не был загружен до этого), находит в нем процедуру (без параметров) DoEndlessLoop() и активирует ее. Если при выполнении этой процедуры происходит нечто плохое, например, возникает исключительная ситуация (или в терминологии БлэкБокса происходит system trap), то выполнение этой команды останавливается.

Вот и все.

В UNIX или в Windows аналогичным образом, например, может завершиться процесс порожденный командами ./ADoEndlessLoop.out или ADoEndlessLoop.exe.

Можно самому, так сказать, снять задачу, т. е. отменить выполнение зациклившейся команды нажав на Ctrl + Break (хоть и не мгновенно, но срабатывает). Ctrl + Break рассматривается как исключение, порожденное пользователем. Сама процедура может самостоятельно сгенерировать исключительную ситуацию вызвав ASSERT(condition, num); с condition = FALSE — выполнение текущей команды будет остановлено.




Однако есть существенное отличие между Оберон системами и UNIX/Windows касающееся судьбы переменных:

Когда выполнение текущей команды останавливается, то что происходит с переменными? А ничего страшного — о судьбе локальных переменных позаботится сборщик мусора, а модульные (статические глобальные) переменные остануться как ни в чем не бывало до тех пор пока модуль не будет явно выгружен из памяти (отдельной командой). Так что можно повтороно запустить хоть ту же самую команду заново и она запустившись обнаружит модульные (статические глобальные) переменные в уже проинициализированном виде, и, в принципе можно запрограммировать ее так, что далее она может начать работу с того места где была прервана. То есть, теоретически возможен горячий перезапуск.


Если ситема позволяет запускать команды параллельно — то вот Вам, пожалуйста, аналог отдельных процессов UNIX/Windows.

Письмо в РСДН касательно программной реализации защиты в ОС Оберон

Уважаемые коллеги! Прежде всего хотел бы предупредить, что я не являюсь ни сторонником, ни противником ОС Оберон и связанных с ней технологий. Также я не являюсь экспертом по ОС Оберон или ОС BlueBottle, поэтому не могу высказываться о том, какая конкретно реализация того или иного механизма применяется в этих ОС.

1. Несколько общефилосовских слов по поводу программно/аппаратной защиты.

Как я уже неоднократно подчеркивал, между програмной и аппаратной защитой нет принципиальной разницей, как нет принципиальной разницы между программной и аппаратной реализацией ЛЮБОГО алгоритма. Теоретически, реализовать машину Тьюринга можно как аппаратно, так и программно.

Есть, однако, разница в УРОВНЕ, на котором будет работать такая защита. Не секрет, что в индустрии IT повсеместно используется многоуровневая (многослойная) организация вычислений, когда один уровень (например, уровень программы на ассемблере) использует другой уровень (уровень железа). Таким образом, неформально можно сказать, что прослеживаются следующие уровни:
1) Чисто аппаратный уровень (триггеры, регистры и прочая схемотехника)
2) Микропрограммный уровень (микрокод)
3) Уровень ассемблера
4) Уровень managed-кода

Строго говоря, на архитектуре х86 мы не можем разделить 1 и 2 уровни, так как у нас нет доступа к микрокоду процессора. Но это не принципиально.

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

Таким образом, в традиционной схеме так называемой аппаратной защиты мы располагаем логику защиты на уровне 1-2
В случае с ОС Оберон логика должна располагаться на уровне 3, так как программы, написанные на Оберон и использующие сборщик мусора можно в какой-то мере считать managed кодом уровня 4. Принципиально, такая защита ничем не хуже, чем защита на уровне 1-2, до тех пор, пока мы не начинаем обходить ее (т.е. не начинаем программировать на ассемблере)


2. Вопросы о процессах и сборщике мусора

Неоднократно высказывался вопрос следующего содержания: Что будет, если процесс (активный объект) начнет вести себя неадекватно и его понадобится убить ? Справится ли с этим сборщик мусора ?
Мне кажется, что во второй части вопроса допущена явная неточность и вот почему.
В данный конкретный момент времени существуют две иерархии объектов:
1) Иерархия ссылок (объект А держит ссылку на объект Б)
2) Иерархия исполнения (метод Foo объекта А вызвал метод Bar объекта Б и теперь метод Bar исполняется)

Вопрос об "убийстве активного процесса" не имееет отношения к иерархии ссылок, а имеет отношение к иерархии исполнения. Забавно то, что применение нестандартной терминологии (активный объект) наталкивает нас на неверные интерпретации.

Что такое активный объект ? Это объект, метод которого выполняется в многозадачной или одно задачной среде. Что такое "убить активный объект"? Это по сути не означает "удалить объект", это означает "приостановить выполнение метода объекта, т.е. сделать его пассивным". Сборщик мусора тут вообще ни при чем. Если кто-то сохранил ссылку на объект, ничего страшного в этом нет.



3. Субъективное мнение о безопасности процессов в едином адресном пространстве

На необходимость наличия различных адресных пространств в большой степени влияют применяемые в данной конкретной системе инструменты программирования. Может оказаться, в частности, что разделение пространств вовсе и не требуется (пример — многопоточность Mozart Oz) или наоборот, жизненно необходимо. В любом случае, приходится опираться на некоторые априорные знания о тех программах, что будут исполняться в системе. Безопасность процессов в едином адресном пространстве (если это требуется) может быть достигнута чисто программными средствами и типичное тому подтверждение — Erlang.

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

Проблема разделения полномочий между уровнями очень похожа на проблему яйца и курицы. Верхние слои часто используют какую-либо функциональность, ее (из соображений, например, скорости исполнения) переносят на нижние уровни, затем новые системы верхних уровней уже "приговариваются" к использованию такой функциональности. Образуется обратная связь. Так и крутится весь мир. Когда появляется программное обеспечение, не использующее функциональность нижних уровней ("еретическое" программное обеспечение), то ему, разумеется трудно конкурировать по многим причинам с "традиционным" программным обеспечением, даже не смотря на то, что теоретически (в идеальном варианте), если бы были разработаны ВСЕ слои (1,2,3,4) под новое программное обеспечение и при этом затрачены те же средства, что были затрачены на разработку "традиционных" слоев, то результат был бы даже лучше. Доказать полезность "еретического" программного обеспечения можно только в тех редких случаях, когда оно на порядок лучше традиционного или когда имеет специальную сферу применения.

4. Выводы

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

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

C>Сергей Губанов пишет:
>> Копий нет:
>>
>>MODULE M
>> VAR K: INTEGER;
>>END M.
>>
>> переменная M.K — одна на всю систему.

C>То есть, если пользователь Вася загрузит модуль "Photoshop", то
C>пользователь Петя уже не сможет его загрузить?

C>Или Оберон — исключительно однопользовательский?

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

Вот Вам три фотошопа одновременно:

VAR p1,p2,p3: Photoshop.View;
BEGIN
  p1 := Photoshop.New();
  p2 := Photoshop.New();
  p3 := Photoshop.New();

  Views.OpenView(p1);
  Views.OpenView(p2);
  Views.OpenView(p3);

Количество загружаемых одновременно программ не связано с одно- или много-пользовательностью системы. В принципе, теоретически, можно вообразить многопользовательскую систему, в которой действительно каждая программа может быть загружена в одном экземпляре. И в которой действительно, Петя и Вася работающие удаленно на одном и том же компьютере не смогут одновременно запустить фотошоп. Мультизадачность и мультипользовательность — ортогональные понятия.

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

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

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

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

Под системным списоком указателей я имел в виду внутренности ядра системы (или рантайма) — то что скрыто от приложений. А то что приложения будут написаны криво или прямо, на безопасность системы уже не влияет, она уже защищена.

Сергей Губанов пишет:

> # Из того что модульные переменные существуют в единственном экземпляре
> не следует, что каждая программа может быть запущена в одном экземпляре.
>
> Вот Вам три фотошопа одновременно:
>
>VAR p1,p2,p3: Photoshop.View;
>BEGIN
> p1 := Photoshop.New();
> p2 := Photoshop.New();
> p3 := Photoshop.New();
>
> Views.OpenView(p1);
> Views.OpenView(p2);
> Views.OpenView(p3);
>
>
Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не
помогает (даже мешает).

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

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

СГ> Если ситема позволяет запускать команды параллельно — то вот Вам, пожалуйста, аналог отдельных процессов UNIX/Windows.

Например в Aos BlueBottle написанной на языке Active Oberon "тело активного объекта" выполняется параллельно. Гарантируется, что пока активный объект активен, то сборщик мусора его не будет уничтожать даже если внешних ссылок на него не осталось или никогда не было (в ядре хранятся ссылки на все активности), после того как активный объект закончил свою активную деятельность — далее он продолжает "влачить свое существование" уже как обычный объект и будет убит сборщиком мусора как только о нем все забудут.

TYPE
  MyActiveObject = OBJECT
    (* Переменные объекта *)
     VAR x, y, Vx, Vy: REAL;

    (* Методы объекта *)
    PROCEDURE Move()
    BEGIN
    END....
    ...    
  BEGIN {ACTIVE} (* "тело" объекта *)
    (* код приведенный сдесь выполняемый параллельно *)
    (* начинает исполняться после конструирования этого объекта *)
    (* после выполнения этого кода объект перестает быть активным и превращяется в обычный *)
  END;

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

C>Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не
C>помогает (даже мешает).

А если подумать, то можно придумать массу алгоритмов, где будет помогать. Обратитесь к исходникам таких систем...

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

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

Т>>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?
P>>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?

AVC>А чем в этом отношении Оберон хуже?
AVC>В Обероне "плохой" процесс убивается, в Log выводится trap text.
AVC>В данном пункте не вижу разницы.

В этом все и дело. Но что тогда значит "обычные ОС" в интерпретации г-на Трурля?


AVC>А вопрос Трурль задал правильный.
AVC>Противники Оберона постоянно высказываются в том духе, что "убийство процесса" есть главный (чуть ли не единственный) механизм безопасности в ОС.


А зачем держать в памяти взвесившийся процесс? Если его не прибить, то он по-прежнему будет занимать выделенную ему память. Мешать нормальной работе остальных приложений он не сможет, но захваченные им память и другие ресурсы система сможет использовать с большей пользой.

Так что убийство процесса — результат требования экономного использования ресурсов, а не механизм безопасности.

AVC>Вот Трурль и задает простой вопрос: как процесс становится "плохим", когда его пора убивать?

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

Сергей Губанов пишет:

> C>Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не
> C>помогает (даже мешает).
> А если подумать, то можно придумать массу алгоритмов, где будет
> помогать. Обратитесь к исходникам таких систем...

КАКИХ именно систем?

"Активный объект" — это не более чем обычный поток, а переменные модуля
— статические переменные, разделяемые всеми тредами. Это делает их
бесполезными в 99% случаев.

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

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

P>> а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие
P>> могут находиться удаленно и пр.?

S>При чем здесь я?
S>Программист на Обероне может и не знать — компонентная среда и все такое.
Ну это глупости на самом деле Программист почти всегда знает что и откуда, и при этом совсем не обязательно расставлять try/catch вокруг любого вызова.

P>>б — неужто приватные Hashtable могут
P>> кидать исключения и это составляет проблему?

S>При чем здесь Hashtable?
Это в вопросу о том, что ты знаешь что может упать, а что нет.

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

S>Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не читаю.
Обертка нужна
— для получения сообщений о том, что она отвалилась, и изъятии её при этом из разных там коллекций.
— для попыток переподключения.
— для сохранения возможности вызвать некоторые свойства уже после того, как объект отвалился (например, кешированное Name или IsAlive = false)

Под .Net можно, конечно, решить и без обертки — при помощи синков.

P>> Как много программ
P>> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
P>> или UndefinedBehaviorException при new ?

S>Почем я знаю? Лично мне такую возможность часто приходится учитывать.
Лично вы под C++ ? Тока не надо быть меня ногами.

Hello, Poudy!
You wrote on Tue, 01 Feb 2005 10:08:51 GMT:

P> Ну это глупости на самом деле Программист почти всегда знает что и
P> откуда, и при этом совсем не обязательно расставлять try/catch вокруг
P> любого вызова.

Знает, ага. Только часто забывает Да и вообще все развитие средств
программирования направлено на то, чтобы объем необходимых знаний уменьшить,
а где нельзя уменьшить — заменить глобальные знания деталей локальными.
Потому что в голову все детали программы не помещаются.

P>>> б — неужто приватные Hashtable могут
P>>> кидать исключения и это составляет проблему?

S>> При чем здесь Hashtable?
P> Это в вопросу о том, что ты знаешь что может упать, а что нет.

Ну вообще-то и приватные Hashtable упасть могут Особенно если физически
размещены на другом компьютере, а приватными стали после того, как ссылку на
них в конструктор передали.

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

S>> Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не
S>> читаю.
P> Обертка нужна
P> — для получения сообщений о том, что она отвалилась, и изъятии её при
P> этом из разных там коллекций. — для попыток переподключения.
P> — для сохранения возможности вызвать некоторые свойства уже после того,
P> как объект отвалился (например, кешированное Name или IsAlive = false)

Там и так усе через обертки работает. А обертки параметризованы стратегиями.
Впрочем, не о них речь.

P> Под .Net можно, конечно, решить и без обертки — при помощи синков.
А синки вместе с объектом не отвалятся?

P>>> Как много программ
P>>> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
P>>> или UndefinedBehaviorException при new ?

S>> Почем я знаю? Лично мне такую возможность часто приходится учитывать.
P> Лично вы под C++ ? Тока не надо быть меня ногами.

Надо, надо — за провокацию Естественно, я учитываю не мифические
NotEnougthMemoryException и UndefinedBehaviorException, а вполне реальные
std::bad_alloc и CMemoryException. Которые иногда даже и прилетают таки.

With best regards, Sergey.

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

СГ>2) Ни потоков, ни процессов в объектно ориентированных операционных системах не бывает. Вместо них в объектно ориентированных операционных системах бывают АКТИВНЫЕ ОБЪЕКТЫ. То есть прибиванию подлежит не процесс и не поток, а активный объект (obj := NIL).

Сформулируем задачу так: можно ли устанавливать квоты на количество ресурсов (в первую очередь — на память), которым владеет данный активный объект?
Если несколько активных объектов совместно владеют какой-то памятью (естественно, в типизированном виде) — то как трактовать это с т.з. квот?

Собственно, зачем в виндоузе, юниксе и OS/360 сделано разделение на процессы: чтобы определить зоны ответственности. Менеджеру ресурсов глубоко фиолетово, сколько потоков (представленных активными объектами или банальными хэндлами) существуют в одном процессе, какие между ними зависимости и кто из них жрёт ресурсы. Весь процесс жрёт, и именно он как единое целое будет ограничен (прибит, перепланирован, функция запроса вернёт ошибку — это уже мелочи реализации).

Кодт пишет:

> Собственно, зачем в виндоузе, юниксе и OS/360 сделано разделение на
> процессы: чтобы определить зоны ответственности. Менеджеру ресурсов
> глубоко фиолетово, сколько потоков (представленных активными объектами
> или банальными хэндлами) существуют в одном процессе, какие между ними
> зависимости и кто из них жрёт ресурсы. *Весь процесс* жрёт, и именно
> он как единое целое будет ограничен (прибит, перепланирован, функция
> запроса вернёт ошибку — это уже мелочи реализации).

Еще добавлю: процессы образуют дерево, так что можно сделать и каскадные
ограничения.

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

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

AVC>В Си++ типизация сильнее, чем в Обероне?
AVC>Это Вы баек о пользе шаблонов в Си++ наслушались?
AVC>А как Вам конструкции вида
AVC>

AVC>int foo(void *p)
AVC>{
AVC>  return ((int (*)())p)();
AVC>}
AVC>

Да, сильнее. По стандарту С++, конверсия между void* и void(*)() невозможна; другое дело, что некоторые компиляторы для некоторых платформ (одно из требований — это tiny|large|flat модель памяти) на это плюют.