Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mr. None, Вы писали:
MN>>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>То есть дело не в том можно ли обойтись без GC или нельзя, а в том, что GC — гарант стабильности, устойчивости, безопасности расширяемой системы, в контексте работы с памятью. Без GC расширяемая система УЯЗВИМА по отношению к ошибкам (случайным или намеренным) при работе с памятью.
MN>>А с GC система уязвима по отношению к ошибкам выделения/освобождения других ресурсов, таких как файлы, сокеты и прочее. Потому что не известно, в какой момент сработает GC и освободит ресурс... MN>>Поэтому не надо в GC искать панацею — не найдёте, если руки кривые, то и GC не поможет.
СГ>Естественно GC заведует только памятью. Следить за остальными ресурсами должен программист и это не зависит от того есть ли GC нет ли его.
Ну тогда почему бы программисту не следить и за памятью как за другими ресурсами и обойтись без GC...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Ligen, Вы писали:
СГ>Ага, контролирует, как же!!!!!! А вот я у своего объекта возьму и по злому умыслу сделаю так, чтобы он вовсе не уничтожался тогда когда счетчик ссылок обнуляется. Или, совсем подлянку подложу — он будет самоуничтожаться тогда когда количество ссылок на него превысит 666. Проконтролируйте плиз его... А при наличии GC, я не могу сделать ничего подобного даже по злому умыслу.
<offtop>
Насчет злого умысла ))
Вы, сударь, если я правильно понимаю, проповедуете ОС Оберон, так?
Одним из принципом который является создание ограничений для программиста компилятором до такой степени, что ОС запускает код нескольких программ в едином адресном пространстве?
Так вот, есть ли в этих ОС следующие функции
а) Работы с файлами: создание и запись файлов (а-ля CreateFile, и т.д)
б) Запуска исполняемого файла (а-ля CreateProcess)
Я подозреваю, что есть. Вы поняли мою мысль на счет злого умысла?
</offtop>
Здравствуйте, Трурль, Вы писали:
Т>Вовсе это не естественно. Почему бы системе и не следить за ресурсами?
Потому что для многих ресурсов ленивое освобождение неприемлемо, а алгоритмов, гарантирующих мгновенное освобождение ресурса полностью автоматически пока не придумали.
L>Так вот, есть ли в этих ОС следующие функции L> а) Работы с файлами: создание и запись файлов (а-ля CreateFile, и т.д) L> б) Запуска исполняемого файла (а-ля CreateProcess)
L>Я подозреваю, что есть. Вы поняли мою мысль на счет злого умысла?
Я подозреваю что на это С. Г. ответить не сможет.
В "прозрачной однопроцессной" системе более слабая защита априори.
Возмём Smalltalk. первый "тест" — Compiler:=nil. И тутже эмулятор смаллталка вылетает.
Это самонаводящийся утрирующе излагающий мою мысль пример.
Ничего лучше чем сокеты и их подобия (пайпы итп) для плезио-реалаймового безопасного взаимодействия программ, имхо, ещё никто не придумал. Всмысле чтобы на любой концепции ос можно было это сделать. И вообще когда я пытался спроектироваь (написать специфкацию "ос моей мечты" ака DreamOS, я придумал дерево именованых объектов, которым можно посылать сообщения (и получать соответственно). Процесс представлял собой объект, "понимающий" (как оказалось позже, в смаллталковом смысле) сообщения run, iterate, iddle, terminate. В сообщениях suspend, resume не было необходимсти, т. к. процесс жив пока не обработал сообщение terminate с возвратным кодом TERMINATION_DONE_*. А активен процесс пока обрабатывает iterate или idle. Де факто у меня получалось что процесс любой выглядел примерно так:
public int process(message msg) {
if (msg instanceof idle) {
doiddle();
} else if (msg instanceof terminate {
cleanup();
return 0;
} else if (msg instanceof iterate) {
doiterate();
} else {
processextramsg(msg);
}
}
}
}
такие объекты-процессы поизводны от спецкласса Process_Base, у которого метод process абстрактный, либо вообще имеют метод
public int process(message msg);
Чтобы гарантировать переключение задач, система сама их переключает каждые 100-200 инструкций между теми объектами, которые обрабатывают сообщения, и не в состоянии waiting.
Начинает свою жизнь процесс с получаения сообщения init, сожержащего ссылку на "контекст процесса". Это:
менеджер памяти;[/*]
менеджер доступа к системному дереву объектов;[/*]
объект очереди входнящих сообщений;[/*]
объект очереди исходящих сообщений.[/*]
Все ссылки, ясное дело, read-only, указателей ясен пень нет. в место них — accelerative memory chunks.
Как уже м. б. догадаться. эта ось — среда "интерпретации".
Объект видит системное дерево объектов в той мере, в которой ему это позволяет система downing rights levels. Т. е. "уровни прав творения всегда ниже, чем у творца". Например, есть приложение, зарегестриованное при инсталяции как "стандартное НЕсетевое париложение". Все процессы этой программы будут видеть допустим диски, с фильтром прав пользователя. А сеть она не увидит вообще. Ей корень network.* не будет просто доступен. "Какие там акселеративные интерфейсы:? не смешите мои тапочки!" скажет несетевому приложению менеджер доступа к дереву объектов в ответ на соотв. запрос. например
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Объект видит системное дерево объектов в той мере, в которой ему это позволяет система downing rights levels. Т. е. "уровни прав творения всегда ниже, чем у творца". Например, есть приложение, зарегестриованное при инсталяции как "стандартное НЕсетевое париложение". Все процессы этой программы будут видеть допустим диски, с фильтром прав пользователя. А сеть она не увидит вообще. Ей корень network.* не будет просто доступен. "Какие там акселеративные интерфейсы:? не смешите мои тапочки!" скажет несетевому приложению менеджер доступа к дереву объектов в ответ на соотв. запрос. например ВП>
ВП>И т д итп. ВП>gc не панацея. но единый менеджер ресурсов — это может стать бронзовой пулей. ВП>Не серебряной, подчёркиваю
Вот это, конечно, интересно. Но означает ли это, что несетевое приложение никогда не увидит сеть даже опосредованно?
Вот на что я намекаю: допустим есть у нас что-то очень простое. Ну, скажем, текстовый редактор. И надо ему уметь файлы хранить (я извиняюсь за такой пример — возможно, в полноценной ОО-ОС не будет никаких файлов, а будет просто встроенная в объекты персистентность. Тем не менее, вопрос останется почти таким же). Очевидно, что из соображений безопасности мы должны закрыть ему доступ к сети (ибо нефиг текстовому редактору сеткой пользоваться). И вот есть у нас с другой стороны файловый менеджер. И плугин к нему, который позволяет удаленные файлы как часть FS видеть (этакий Network Neigborhood). А теперь, внимание, вопросы:
1. Сможем ли мы сделать такой плагин к файловому менеджеру, не объявляя сам файловый менеджер сетевым?
2. Сможем ли мы из нашего текстового редактора как-то общаться с этим файловым менеджером и обрабатывать, например, драг-н-дроп удаленного файла в наш редактор для открытия?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Трурль, Вы писали:
Т>>Вовсе это не естественно. Почему бы системе и не следить за ресурсами?
AVK>Потому что для многих ресурсов ленивое освобождение неприемлемо, а алгоритмов, гарантирующих мгновенное освобождение ресурса полностью автоматически пока не придумали.
Есть подозрение, что такие ресурсы будут постепенно изыматься из обращения.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Волк-Призрак, Вы писали:
ВП>>Объект видит системное дерево объектов в той мере, в которой ему это позволяет система downing rights levels. Т. е. "уровни прав творения всегда ниже, чем у творца". Например, есть приложение, зарегестриованное при инсталяции как "стандартное НЕсетевое париложение". Все процессы этой программы будут видеть допустим диски, с фильтром прав пользователя. А сеть она не увидит вообще. Ей корень network.* не будет просто доступен. "Какие там акселеративные интерфейсы:? не смешите мои тапочки!" скажет несетевому приложению менеджер доступа к дереву объектов в ответ на соотв. запрос. например ВП>>
ВП>>И т д итп. ВП>>gc не панацея. но единый менеджер ресурсов — это может стать бронзовой пулей. ВП>>Не серебряной, подчёркиваю S>Вот это, конечно, интересно. Но означает ли это, что несетевое приложение никогда не увидит сеть даже опосредованно? S>Вот на что я намекаю: допустим есть у нас что-то очень простое. Ну, скажем, текстовый редактор. И надо ему уметь файлы хранить (я извиняюсь за такой пример — возможно, в полноценной ОО-ОС не будет никаких файлов, а будет просто встроенная в объекты персистентность. Тем не менее, вопрос останется почти таким же). Очевидно, что из соображений безопасности мы должны закрыть ему доступ к сети (ибо нефиг текстовому редактору сеткой пользоваться). И вот есть у нас с другой стороны файловый менеджер. И плугин к нему, который позволяет удаленные файлы как часть FS видеть (этакий Network Neigborhood). А теперь, внимание, вопросы: S>1. Сможем ли мы сделать такой плагин к файловому менеджеру, не объявляя сам файловый менеджер сетевым? S>2. Сможем ли мы из нашего текстового редактора как-то общаться с этим файловым менеджером и обрабатывать, например, драг-н-дроп удаленного файла в наш редактор для открытия?
Ээээ.....
Ну тут достаточно просто делается — "симуяция локального узла (папки)".
Т. е. программа для работы с удалёнными файлами создаёт объекты своего класса, наследуя от File и Folder, и суёт их скажем в local/users/петя васечкин/контроьные/сервак/.
А всё, что может видеть и понимает File- и Folder-узлы, увидит после оповещения о изменеиях в local/users/. Но это не значит, что проге разрешат не только
разрешат, потому что это explore и execute, а не create.
На create тожеправа нужно. Даже если у тя есть права на sendmsg|getmsg|explore|execute.
execute в данном случае означает не тлько собственно execute но и получение и применение акселеративных интерфейсов (чемто напоминает COM с рефлексией).
Вообще думаю что следующих прав будет достаточно:
create — создание объекта клсса
destroy — "убийство" объекта класса
rename — переименование объекта
cretemirror — создание объекта-зеркала (это грубо говоря ссылки на копии объектов, доступные так будто они были созданы той программой, которая попросила зеркало. Требует права create и execute.
read — отправка сообщения sys_read и получение sys_read_result
write — соотв. sys_write и sys_write_result
explore — поиск в дереве по имени и прочим параметрам (дата создания, изменения, последний объём в хранилище, требуемые минимальные уровни прав и др.
execute|getaccelerativeinterface
sendmsg — отправка объекту чего-либо, кроме sys_read и sys_write
recvmsg — получение от объекта чего либо кроме sys_read_result и sys_write_result
Каждое "право" имеет ранги от 0 до 0x0FFFFFFF. Объекты внутрениие ядра имеют ранг 0x0FFFFFFF, ессесно, по всем позициям. Этот ранг имеет всё, что создаётся до контроллера прав, который создаётся последний с такими рангами.
Прога, создавая объект в глобальном дереве, может назаначить ему ранги толлько ниже собственного ранга (ранга объекта в методе которого вызывается
Здравствуйте, Трурль, Вы писали:
AVK>>Потому что для многих ресурсов ленивое освобождение неприемлемо, а алгоритмов, гарантирующих мгновенное освобождение ресурса полностью автоматически пока не придумали.
Т>Есть подозрение, что такие ресурсы будут постепенно изыматься из обращения.
Ну как изымутся, так и проблема исчезнет. Только сильно сомневаюсь я в этом.
Здравствуйте, Mr. None, Вы писали:
MN>Ну тогда почему бы программисту не следить и за памятью как за другими ресурсами и обойтись без GC...
Сравни кол-во выделений памяти, и других ресурсов. Небо и земля.
Проблема не решается smart pointerами. А если учесть что: они не входят в спецификацию, и следовательно не обязательно для обучения, и следовательно не обязательно для применения (во многих случаях, их и не применишь). А теперь представь себе программиста, только что выучившего азы науки, и работающего на какое-то предприятие где даже научиться не у кого. Месяц пишет программу, два месяца вычищает ошибки. GC это не панацея, но положительного в нем очень много. Свою роль он выполняет. При правильном теоретическом подходе, любую вещь можно испортить. Просто в данном случае, это будет значительно сложней.
Немного перефразирую ваше предложение: А почему бы GC не следить за остальными ресурсами?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Mr. None, Вы писали:
MN>>Ну тогда почему бы программисту не следить и за памятью как за другими ресурсами и обойтись без GC... GZ>Сравни кол-во выделений памяти, и других ресурсов. Небо и земля.
Сравните проблемы, возникающие из-за утечки памяти и утечки других ресурсов. Небо и земля. Если у вас будет течь память, то программа будет работать и не упадёт, пока не исчерпает всю VM, а это ой как много — если у вас не сервер, то ничего страшного в этом нет. А если она не освободит какой-нибудь важный файл, то при следующей попытке его захвата всё рухнет к чёртовой матери.
GZ>Немного перефразирую ваше предложение: А почему бы GC не следить за остальными ресурсами?
И как вы себе это представляете, например, на примере освобождения файла? Вообще-то он следит — когда закончится VM, запустится GC и убъёт потеряный объект класса CFile, при этом вызовется его деструктор и файл освободиться. Но такое решение меня не устраивает — может память вообще не кончится! Чтобы решить проблему слежения за всеми ресурсами, GC должен вызываться каждый раз при выходе за пределы определённого контекста вызова — вышли из цикла, пускаем GC, сделали return пускаем GC. Но в таком случае или машина колом ляжет или мы опять таки придём к идее автоматического размещения на стеке и концепции auto_ptr... Вобщем: "С разума начали, разумом кончили." — Формула любви.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>>>Ну тогда почему бы программисту не следить и за памятью как за другими ресурсами и обойтись без GC... GZ>>Сравни кол-во выделений памяти, и других ресурсов. Небо и земля. MN>Сравните проблемы, возникающие из-за утечки памяти и утечки других ресурсов. Небо и земля.
Совершенно верно — утечки памяти несравнимо страшнее, поскольку обнаружить их сложнее на порядок.
MN> Если у вас будет течь память, то программа будет работать и не упадёт, пока не исчерпает всю VM, а это ой как много — если у вас не сервер, то ничего страшного в этом нет.
Ты когда серверный софт пишешь — вот так не переживаешь особо по поводу ликов? Лок файла отлавливается на раз — обычно код, использующий конкретный залоченый фал находится в одном месте (да и кода, использующего файлы ничтожно мало). А вот если у тебя где то, непонятно где, течет, то это большая задница. И для современного серверного софта это не допустимо, поскольку требования к бесперебойной работе становятся все жестче, а гарантировать нормальное поведение лика не на тестовых задачках, а под реальной нагрузкой никто не может.
GZ>>Немного перефразирую ваше предложение: А почему бы GC не следить за остальными ресурсами? MN>И как вы себе это представляете, например, на примере освобождения файла? Вообще-то он следит — когда закончится VM, запустится GC и убъёт потеряный объект класса CFile, при этом вызовется его деструктор и файл освободиться. Но такое решение меня не устраивает — может память вообще не кончится! Чтобы решить проблему слежения за всеми ресурсами, GC должен вызываться каждый раз при выходе за пределы определённого контекста вызова — вышли из цикла, пускаем GC, сделали return пускаем GC.
Такое бывает. Но часто подобное можно обойти, к примеру запретив напрямую лезть к файлам, а открытые файлы помещать в пул. Получается, что если эти файлы использует только твое приложение, то висящий лок не страшен.
Здравствуйте, AndrewVK, Вы писали:
GZ>>>Сравни кол-во выделений памяти, и других ресурсов. Небо и земля. MN>>Сравните проблемы, возникающие из-за утечки памяти и утечки других ресурсов. Небо и земля.
AVK>Совершенно верно — утечки памяти несравнимо страшнее, поскольку обнаружить их сложнее на порядок.
MN>> Если у вас будет течь память, то программа будет работать и не упадёт, пока не исчерпает всю VM, а это ой как много — если у вас не сервер, то ничего страшного в этом нет.
AVK>Ты когда серверный софт пишешь
Вы там апелировали к программисту, который только что выучил азы науки и который ничего не знает про смарт-поинтеры и которому GC поможет... Так вот — такого не посадят сервер писать, а нам с вами что GC что смарт-поинтер — всё едино ...
Вобщем кончаем этот флейм — всё равно все при своём мнение остануться, пошли к новому году готовиться, у меня как раз медовуха поспела .
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
GC кроме всего прочего позволяет изменить и сами языки программирования. Например, избавиться от указателей. Т.е. и языки становятся "более защищенными" — не позволяют писать совсем уж опасный код.
Здравствуйте, Mr. None, Вы писали:
MN>Ну тогда почему бы программисту не следить и за памятью как за другими ресурсами и обойтись без GC...
А заодно и за регистрами, прерываниями и т. д.
Здравствуйте, Mr. None, Вы писали:
MN>Вы там апелировали к программисту, который только что выучил азы науки и который ничего не знает про смарт-поинтеры и которому GC поможет... Так вот — такого не посадят сервер писать
GZ>>Немного перефразирую ваше предложение: А почему бы GC не следить за остальными ресурсами? MN>И как вы себе это представляете, например, на примере освобождения файла? Вообще-то он следит — когда закончится VM, запустится GC и убъёт потеряный объект класса CFile, при этом вызовется его деструктор и файл освободиться. Но такое решение меня не устраивает — может память вообще не кончится! Чтобы решить проблему слежения за всеми ресурсами, GC должен вызываться каждый раз при выходе за пределы определённого контекста вызова — вышли из цикла, пускаем GC, сделали return пускаем GC. Но в таком случае или машина колом ляжет или мы опять таки придём к идее автоматического размещения на стеке и концепции auto_ptr... Вобщем: "С разума начали, разумом кончили." — Формула любви.
GC постоянно развивается и проблема описанная тобой может разруливаться и компилятором, обрабатывая код и выискивая объекты на которые нет исходящих ссылок из тела метода. Даже на данном этапе, для GC генерируется множество подсказок. Все течет, все меняется ....
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> GC постоянно развивается и проблема описанная тобой может разруливаться и компилятором, обрабатывая код и выискивая объекты на которые нет исходящих ссылок из тела метода. Даже на данном этапе, для GC генерируется множество подсказок. Все течет, все меняется ....
Вот когда притечёт и измениться. И GC сможет решить указанную мной проблему, вот тогда поговорим, а сейчас — это рассуждение о возмолжности существования в вакууме сферических коней и других псевдоматериальных сущностей.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, Ligen, Вы писали:
SK>А мне глубоко не пофигу. Посмотри struts, hibernate и т.д. Такие библиотеки на C++ сделать невозможно, язык не позволяет. Так, что решая те задачи, на которые заточены это бибилитеки, на С++ тебе будет не весело совсем. Точнее, может и весело, но тяжело и долго.
Почему не позволяет? У меня ОРМ работало на С++, не жаловался.
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Mr. None, Вы писали:
K>GC кроме всего прочего позволяет изменить и сами языки программирования. Например, избавиться от указателей. Т.е. и языки становятся "более защищенными" — не позволяют писать совсем уж опасный код.
Указатели — это палка о двух концах. С другой стороны, это наиболее быстрая адресация памяти.
Почему бы системе и не следить за ресурсами? 
