Flash-04 wrote:
тогда и я могу сказать что в Windows накладные расходы на создание нового процесса-двойника почти нулевые. Ведь код уже загружен в память, а Windows использует одну и ту же страницу с кодом (Execute-only) для каждого процесса созданного для того же исполняемого файла.
Сказать-то Вы можете, только это не будет правдой.
fork содает клон процесса. т.е. полную копию, причем даже без копирования, клон получает копию всех ресурсов (без копирования), ну там сокеты, файлы.
В виндовс создается новый процесс с нуля.
Или я заблуждаюсь?
Расскажите, f_evgeny, как можно создать копию без копирования? Как называется этот магический процесс? Мне это жутко пригодится...
Или вы имеете ввиду, что не мы копируем, а кто-то другой? Это было бы большим разочарованием...
f_evgeny wrote:Строго по моим тезисам. Не находите?
не совсем. я уже написал что правильное приложение не падает никогда, и организация в виде процессов ему не нужна.
То что Вы написали, не значит, что все приложения правильные.
По моему, сделали правильно, прикинули историю, уровень требований к надежности и безопасности бюджет, сроки и исходя из этого выбрали архитектуру.
Вы же рассуждаете как "русский программист", надо было все переписать с нуля на новой "правильной" библиотеке.
MAKAPOB wrote:
Расскажите, f_evgeny, как можно создать копию без копирования? Как называется этот магический процесс? Мне это жутко пригодится...
Или вы имеете ввиду, что не мы копируем, а кто-то другой? Это было бы большим разочарованием...
MAKAPOB wrote:
Расскажите, f_evgeny, как можно создать копию без копирования? Как называется этот магический процесс? Мне это жутко пригодится...
Или вы имеете ввиду, что не мы копируем, а кто-то другой? Это было бы большим разочарованием...
Так я и думал... Развеялись грезы о создании копии без копирования... Вы с утверждениями и формулировками-то поосторожнее - внушаете, понимаешь, пустые надежды... Мне в свое время на физтехе за лабу по физике трояк влепили - за формулировку в принципе правильную, но двусмысленную... Мы же точными науками занимаемся, а не стихи пишем
MAKAPOB wrote:
Расскажите, f_evgeny, как можно создать копию без копирования? Как называется этот магический процесс? Мне это жутко пригодится...
Или вы имеете ввиду, что не мы копируем, а кто-то другой? Это было бы большим разочарованием...
так он все равно реализован программно. у x86 нет такой команды - "скопировать страницу при обращении к ней" есть page fault, а OS обрабатывает это исключение. Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
Not everyone believes what I believe but my beliefs do not require them to.
MAKAPOB wrote:Мне в свое время на физтехе за лабу по физике трояк влепили - за формулировку в принципе правильную, но двусмысленную... Мы же точными науками занимаемся, а не стихи пишем
[off]это ктож такой зверь был? [/off]
Not everyone believes what I believe but my beliefs do not require them to.
f_evgeny wrote:Зомби, тут идет мирная беседа, а Вы все ищете п-бки. Это не наш стиль.
Да какие еще "п-бки"?
С точки зрения производительности имеется смысл запихать все компоненты делающие много системных вызовов в kernel mode. Более того, если получается обеспечить безопасность другими способами (например, тщательным тестированием или трансляцией модулей исполняемых в режиме ядра безопасным компилятором), то это отличный рабочий вариант.
Объясните, почему то что тонкая прослойка между пользовательским кодом и драйвером и железом видеокарточки (что есть более сложные и намного хуже тестированные вещи) исполняется тоже в режиме ядра вызывает у вас такой ужас?
MAKAPOB wrote:Мне в свое время на физтехе за лабу по физике трояк влепили - за формулировку в принципе правильную, но двусмысленную... Мы же точными науками занимаемся, а не стихи пишем
[off]это ктож такой зверь был? [/off]
[off]Вы смеетесь, с моим склерозом помнить фамилию препа, влепившего мне трояк 29 лет назад? Но урок я запомнил на всю жизнь. Было там чего-то вроде:
- Эта фигня воздействует на эту фигню...
- Чем воздействует?
- Ну, магнитным полем...
- Это "ну, магнитным полем" обходится вам в минус 2 балла.
MAKAPOB wrote:
Так я и думал... Развеялись грезы о создании копии без копирования... Вы с утверждениями и формулировками-то поосторожнее - внушаете, понимаешь, пустые надежды... Мне в свое время на физтехе за лабу по физике трояк влепили - за формулировку в принципе правильную, но двусмысленную... Мы же точными науками занимаемся, а не стихи пишем
Товарищ МАКАРОВ, Вы же учились на физтехе, а пишете как журналист. Какие-то эмоции. Я не виноват в том, что Вы не знакомы с принятой терминологией:
In computing, when a process forks, it creates a copy of itself....
The fork operation creates a separate address space for the child. The child process has an exact copy of all the memory segments of the parent process, though if copy-on-write semantics are implemented actual physical memory may not be assigned (i.e., both processes may share the same physical memory segments for a while). Both the parent and child processes possess the same code segments, but execute independently of each other.
Вы опять на тройку напрашиваетесь.
Golyadkin wrote:
Так сервера писали лет двадцать пять тому назад. Когда число одновременных запросов исчислялось сотнями.
Товарищ Голядкин, не люблю такую манеру изложения, попахивает журноламерством. Мне больше нравится так: Прцессы по сравнению с тредами потребляют на 20-30 процентов больше процессорного времени на переключение контекста.
Flash-04 wrote:Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
А вот тут Вы не совсем правы, добиваемся мы того, что все окружение, которое мы читаем мы получаем по наследству, и только то, куда мы пишем нам нужно выделять.
Очевидно, мне кажется.
Zombie416 wrote:Объясните, почему то что тонкая прослойка между пользовательским кодом и драйвером и железом видеокарточки (что есть более сложные и намного хуже тестированные вещи) исполняется тоже в режиме ядра вызывает у вас такой ужас?
Такая архитектура мне нравится больше по многим причинам, в частности я считаю, что это более грамотный дизайн и дает большие возможности для изменений с минимальными затратами. Вы, конечно, можете иметь другое мнение.
Flash-04 wrote:Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
А вот тут Вы не совсем правы, добиваемся мы того, что все окружение, которое мы читаем мы получаем по наследству, и только то, куда мы пишем нам нужно выделять.
Очевидно, мне кажется.
а фиг вы лучше подумайте вот над каким противоречием: если у вас есть область динамических данных, то как обеспечить чтобы потомок поимел её точную копию, если она сразу не скопирована была? либо надо копировать сразу, либо строить довольно сложный диспетчер памяти который будет такие изменения отслеживать, либо тупо отображать одну и ту же writable страницу памяти в оба адресных пространства. При этом первые два подхода будут дорогостоящими, а последний - напрочь убъет так восхвалаемую вами концепцию безопасности процессов и попутно создаст трудно уловимые баги.
Так что куда ни кинь - всюду клин
что все окружение, которое мы читаем мы получаем по наследству
вы читаете что я пишу? В Windows окружение "близнецов" шарится.
Not everyone believes what I believe but my beliefs do not require them to.
f_evgeny wrote:Такая архитектура мне нравится больше по многим причинам, в частности я считаю, что это более грамотный дизайн и дает большие возможности для изменений с минимальными затратами. Вы, конечно, можете иметь другое мнение.
В чем грамотный дизайн?
Задача. У вас есть видеокарта которая умеет, посредством собственного драйвера и аппаратно, исполнять все или почти все вызовы некоторого API (GDI/OpenGL/DirectX не суть важно). Все это не просто в kernel mode, но еще и с электрическим доступом к шине, собственному вентилятору и нагревателю на сотни ватт - при злоупотреблении может черный дым из корпуса повалить
И у вас есть пользовательская программа, в user mode, делающая вызовы этого API.
Вопрос: какая разница где находится пол-процента complexity обеспечивающей доставку сообщений от user mode к драйверу? Притом что засовывание в kernel mode существенно улучшает производительность. А производительность в данном вопросе имеет колоссальное значение.
f_evgeny wrote:Товарищ МАКАРОВ, Вы же учились на физтехе, а пишете как журналист. Какие-то эмоции. Я не виноват в том, что Вы не знакомы с принятой терминологией ... Вы опять на тройку напрашиваетесь.
Цитируем вас:
fork содает клон процесса. т.е. полную копию, причем даже без копирования, клон получает копию всех ресурсов (без копирования),
Тройка.
(Полагаете, преп не знал, что фигня на фигню воздейтвует именно магнитным полем? Был не знаком с терминологией? Нет - он учил не делать заявлений, которые выставят заявляющего... ммм... в ложном свете.
Человека, сделавшего заявление, приведенное выше, я сочту полным невеждой)
Flash-04 wrote:Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
А вот тут Вы не совсем правы, добиваемся мы того, что все окружение, которое мы читаем мы получаем по наследству, и только то, куда мы пишем нам нужно выделять.
Очевидно, мне кажется.
а фиг вы лучше подумайте вот над каким противоречием: если у вас есть область динамических данных, то как обеспечить чтобы потомок поимел её точную копию, если она сразу не скопирована была? либо надо копировать сразу, либо строить довольно сложный диспетчер памяти который будет такие изменения отслеживать, либо тупо отображать одну и ту же writable страницу памяти в оба адресных пространства. При этом первые два подхода будут дорогостоящими, а последний - напрочь убъет так восхвалаемую вами концепцию безопасности процессов и попутно создаст трудно уловимые баги.
Так что куда ни кинь - всюду клин
что все окружение, которое мы читаем мы получаем по наследству
вы читаете что я пишу? В Windows окружение "близнецов" шарится.
- По третьему варианту и багов нет. В основном базируется на механизмах процессора. Однако переписывать главу из книжки я не буду.
- Вы про CreateProcess? Если да, то например у Танненбаума написано по другому, все создается заново.
Flash-04 wrote:Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
А вот тут Вы не совсем правы, добиваемся мы того, что все окружение, которое мы читаем мы получаем по наследству, и только то, куда мы пишем нам нужно выделять.
Очевидно, мне кажется.
а фиг вы лучше подумайте вот над каким противоречием: если у вас есть область динамических данных, то как обеспечить чтобы потомок поимел её точную копию, если она сразу не скопирована была? либо надо копировать сразу, либо строить довольно сложный диспетчер памяти который будет такие изменения отслеживать, либо тупо отображать одну и ту же writable страницу памяти в оба адресных пространства. При этом первые два подхода будут дорогостоящими, а последний - напрочь убъет так восхвалаемую вами концепцию безопасности процессов и попутно создаст трудно уловимые баги.
Так что куда ни кинь - всюду клин
что все окружение, которое мы читаем мы получаем по наследству
вы читаете что я пишу? В Windows окружение "близнецов" шарится.
- По третьему варианту и багов нет. В основном базируется на механизмах процессора. Однако переписывать главу из книжки я не буду.
- Вы про CreateProcess? Если да, то например у Танненбаума написано по другому, все создается заново.
Если что-то непонятно, я дал ссылку на литературу. Если и в литературе, что-то непонятно, спрашивайте, я не гуру, но постараюсь помочь. А мне в свою очередь непонятно, чего Вы хотите.
Zombie416 wrote:Вопрос: какая разница где находится пол-процента complexity обеспечивающей доставку сообщений от user mode к драйверу? Притом что засовывание в kernel mode существенно улучшает производительность. А производительность в данном вопросе имеет колоссальное значение.
Извините, Зомби, у меня кончается время. Постараюсь обдумать и ответить завтра. ОК?
f_evgeny wrote:- По третьему варианту и багов нет. В основном базируется на механизмах процессора. Однако переписывать главу из книжки я не буду.
- Вы про CreateProcess? Если да, то например у Танненбаума написано по другому, все создается заново.
похоже у нас немного разное представление как работает механизм трансляции и защиты памяти в x86 поясните пожалуйста.
А что CreateProcess? AFAIK Windows не держит копии страниц с одим и тем же кодов для разных процессов запущенных из одного и того же файла.
Not everyone believes what I believe but my beliefs do not require them to.
Ведь код уже загружен в память, а Windows использует одну и ту же страницу с кодом (Execute-only) для каждого процесса созданного для того же исполняемого файла.
от того что он более дорогой, он не становится менее правильным 
есть page fault, а OS обрабатывает это исключение. Всего что вы добиваетесь таким подходом - копирование памяти происходит не за один прием, а становится on-demand и размазывается по времени.
[/off]
вы лучше подумайте вот над каким противоречием: если у вас есть область динамических данных, то как обеспечить чтобы потомок поимел её точную копию, если она сразу не скопирована была? либо надо копировать сразу, либо строить довольно сложный диспетчер памяти который будет такие изменения отслеживать, либо тупо отображать одну и ту же writable страницу памяти в оба адресных пространства. При этом первые два подхода будут дорогостоящими, а последний - напрочь убъет так восхвалаемую вами концепцию безопасности процессов и попутно создаст трудно уловимые баги.