Здравствуйте, Borisman2, Вы писали:
B>Господа! Дискуссия по многозадачности и убиваемости процессов, мне кажется, начинает сводиться к следующему вопросу:
B>1) Что будет, если я попытаюсь выстрелить себе в ногу при помощи кода вида:
B>while(True) { B> list.append(1) B>} B>(ну или как это будет выглядеть на Оберон-2)
А что будет, если пальнуть вот таким кодом?
crazy.bat:
Здравствуйте, Трурль, Вы писали:
B>>1) Что будет, если я попытаюсь выстрелить себе в ногу при помощи кода вида: B>>while(True) { B>> list.append(1) B>>} B>>(ну или как это будет выглядеть на Оберон-2)
Т>А что будет, если пальнуть вот таким кодом? Т>crazy.bat: Т>
Т>loop:
Т>start crazy.bat
Т>goto loop
Т>
Поубывав бы!
Windows-95 умерла, не охнув.
К моему удивлению, Windows XP тоже не удалось вывести из состояния "грогги".
Она как-бы не умерла, но, из-за засилья модальных окошек, все остальные приложения (включая Task Manager) оказались недоступными.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Borisman2 пишет:
> Однако, странная постановка вопроса! Правильный ответ — конечно, > отстрелите себе ногу!!! И результат мало зависит от конкретной ОС или > там от сборщика мусора. > Тем не менее. Когда апологеты Оберона отвечают, что надо УДАЛИТЬ > АКТИВНЫЙ ОБЪЕКТ, который выполняет данный код, противники (иногда) > начинают измываться — "эта мол что, оберон мой объект прибил??? Ай, > нехорошо...." Вы уж определитесь, что вам нужно. И замените термин > "процесс" на термин "активный объект"
Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так
удалить "активный объект". Это приведет к куче проблем, так как на
удаленный объект могут ссылаться другие активные объекты, или если
активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не
возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы в
dotNET, а это тянет за собой длиныый список вопросов о маршаллинге,
сериализации и т.д.
И в итоге получится аналог .NET, только с гораздо более уродливым
языком, чем C# и кучей других недостатков (отсутствием стандарта
интероперабельности и т.п.).
Здравствуйте, Cyberax, Вы писали:
C>Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так удалить "активный объект". Это приведет к куче проблем, так как на удаленный объект могут ссылаться другие активные объекты, или если активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы в dotNET, а это тянет за собой длиныый список вопросов о маршаллинге, сериализации и т.д.
Среда .NET запускается отдельно для каждого процесса (именно поэтому каждая запущенная .NET программа захватывает очень много памяти). Таким образом внутри каждой .NET системы процессов вообще нет (процесс — это она сама) там есть только потоки. Вот если бы .NET была одна единственная на все процессы — вот другое дело.
Вы сами возьмите и попробуйте в .NET программе удалить поток. Далее цитирую Вас же: Это приведет к куче проблем, так как на этот поток могут ссылаться другие потоки, или если поток использует дефецитные ресурсы....
C>И в итоге получится аналог .NET
Наоборот, это .NET есть аналог Оберон систем, разрабатываемых с 1985 года.
Здравствуйте, Cyberax, Вы писали:
C>И в итоге получится аналог .NET, только с гораздо более уродливым C>языком, чем C# и кучей других недостатков (отсутствием стандарта C>интероперабельности и т.п.).
Трудно проидумать что-либо более уродливое, чем C#.
Сергей Губанов пишет:
> C>Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так > удалить "активный объект". Это приведет к куче проблем, так как на > удаленный объект могут ссылаться другие активные объекты, или если > активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не > возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы > в dotNET, а это тянет за собой длиныый список вопросов о маршаллинге, > сериализации и т.д. > Среда .NET запускается отдельно для каждого процесса (именно поэтому > каждая запущенная .NET программа захватывает очень много памяти).
Ничуть. Большая часть DLL-ок и заJITенного кода разделяется между
процессами.
> Таким образом внутри каждой .NET системы процессов вообще нет (процесс > — это она сама) там есть только потоки. Вот если бы .NET была одна > единственная на все процессы — вот другое дело.
В .NET есть AppDomain'ы — это аналоги процессов, по сути. Объекты между
AppDomain'ами НЕЛЬЗЯ передавать напрямую.
> Вы сами возьмите и попробуйте в .NET программе удалить поток. Далее > цитирую Вас же: Это приведет к куче проблем, так как на этот поток > могут ссылаться другие потоки, или если поток использует дефецитные > ресурсы....
Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно
будут освобождены все занятые им ресурсы, а на других доменах это не
скажется — так как объекты разных доменов не могут ссылаться друг на
друга напрямую.
> C>И в итоге получится аналог .NET > Наоборот, это .NET есть аналог Оберон систем, разрабатываемых с 1985 года.
Какое самомнение Оберон тоже натащил концепций из кучи разных языков.
Трурль пишет:
> C>И в итоге получится аналог .NET, только *с гораздо более уродливым ** > C>языком, чем C#* и кучей других недостатков (отсутствием стандарта > C>интероперабельности и т.п.). > Трудно проидумать что-либо более уродливое, чем C#.
Фанат VB? Понимаю...
> Мы еще посмотрим, кто из нас убогий.
Рынок уже давно решил — это выражается в количестве паскалевидного софта
по отношению ко всему остальному.
Здравствуйте, Кодёнок, Вы писали:
Кё>Microsoft не суется с Windows во встроенные системы с повышенными требованиями к надежности
Поправка: с Windows NT. А вот с Windows CE очень даже сунулась, и не просто в индустрию (это не рынок, так, мелочь . Здесь пусть всякие Texas Instruments-ы, Siemens-ы, WindRiver-ы и прочие QNX-сы балуются ), а сразу в автопром . Короче, Билли в очередной раз показал, где лежит стратегия
Здравствуйте, _Obelisk_, Вы писали:
_O_>При реализации автомата нет необходимости в функции, принимающей указатель на саму себя. Там нужен указатель на функцию возвращающию указатель на саму себя. А это достаточно легко моделируется.
Согласен.
Еще можно добавить, что с точки зрения эффективности использовать в реализациях КА указатели на функции довольно глупо. Уж лучше свитчи и генерация кода.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
SilverCloud пишет:
> Кё>Microsoft не суется с Windows во встроенные системы с повышенными > требованиями к надежности > Поправка: с *Windows NT*. А вот с Windows CE очень даже сунулась, и не > просто в индустрию (это не рынок, так, мелочь . Здесь пусть всякие > Texas Instruments-ы, Siemens-ы, WindRiver-ы и прочие QNX-сы балуются > ), а сразу в автопром . Короче, Билли в очередной раз показал, где > лежит стратегия
Истории про зависшие компы с WinCE в hi-end автомобилях все слышали?
Здравствуйте, Cyberax, Вы писали:
C>Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно C>будут освобождены все занятые им ресурсы, а на других доменах это не C>скажется — так как объекты разных доменов не могут ссылаться друг на C>друга напрямую.
Ну и как же Вы после этого бочку на Обероны катить можете?
Там таких ограничений нет —
любой объект может ссылаться на любой другой объект. Активность объекта остановить — какие проблемы?
А что до корректного освобождения всех ресурсов, так этого на автомате быть не может нигде.
Вот память можно почистить и все, что еще-то? Только не надо про закрытие файлов и т. п. так как в объектно ориентированных ОС, файлы — это тоже объекты, только персистентные.
Сергей Губанов пишет:
> C>Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно > C>будут освобождены все занятые им ресурсы, а на других доменах это не > C>скажется — так как объекты разных доменов не могут ссылаться друг на > C>друга напрямую. > Ну и как же Вы после этого бочку на Обероны катить можете? > Там таких ограничений нет — > любой объект может ссылаться на любой другой объект. Активность > объекта остановить — какие проблемы?
Я уже много раз говорил: дефецитные ресурсы...
> А что до корректного освобождения *всех* ресурсов, так этого на > автомате быть не может нигде.
Однако же, в обычных это ОС есть. Все ресурсы ядра корректно
освобождаются при закрытии процесса (открытые файлы, сетевые соединения,
память и т.п.)
> Вот память можно почистить и все, что еще-то? Только не надо про > закрытие файлов и т. п. так как в объектно ориентированных ОС, файлы — > это тоже объекты, только персистентные.
У нас в Обероне, значит, уже и файловой системы нормальной нет? И
сетевых соединений тоже?
SilverCloud пишет:
> C>Истории про зависшие компы с WinCE в hi-end автомобилях все слышали? > Слышали. Вот только подробностей не было. Непонятно, что там у них > зависло. Вы уверены, что это косяки Майкрософт?
Нет, но сам факт того, что МС притягивает к себе такие проблемы (типа
японского премьера, которого компьютер наглухо закрыл в автомобиле) —
весьма интересен.
Здравствуйте, Cyberax, Вы писали:
C>SilverCloud пишет:
>> C>Истории про зависшие компы с WinCE в hi-end автомобилях все слышали? >> Слышали. Вот только подробностей не было. Непонятно, что там у них >> зависло. Вы уверены, что это косяки Майкрософт?
C>Нет, но сам факт того, что МС притягивает к себе такие проблемы (типа C>японского премьера, которого компьютер наглухо закрыл в автомобиле) — C>весьма интересен.
Вроде же объяснили, что там проблема с железом была?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ну сейчас я наподдам еще, не смогу отказать себе в таком удовольствии...
СГ>Вот что значит грамотный дизайн!!! А Вы все шаблоны да генерики, да не нужны они — головой надо думать...
Ну, если уж на то пошло, Лисп тут всех обошел:
Это было для меня большим открытием, я был тогда в аспирантуре, когда я понял, что пол листа кода, в верхней половине страницы 13 в руководстве по Lisp 1.5 был Lisp на самом себе.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
К><skipped>
К>И что дают эти цифры? Ну толку от того, что какую-то операционку запихают в 10 кило? Если всё равно её юзать реально никто не будет, в отличие от тех же линуха и виндовза, ну уж про поддержку разного железа в аосе твоём молчу...
А вот тут ты не прав. Операционки такого плана очень даже полезны при разработки частных систем управления, например. Тут и железо будет ну уж очччень специфическое. Я помню, в институте с мной вместе диплом защищал один человек как раз по этой теме. Реализована была система управления какой-то энергетической установкой, на QNX. Выглядело все очень элегантно.
А иметь ОС, которая содержит всякие вкусности типа сборки мусора, довольно заманчиво...
), а сразу в автопром 
. Короче, Билли в очередной раз показал, где лежит стратегия 
