1 2 3 4 5 6 7 8 9 10 1114
Компонентность .NET шита белыми нитками в избранное  новое горячее всё    подписка   модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 08:12
Оценка: +1 -8 :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :))) :)
Никогда раньше не работал с .NET, но слышал что она является компонентной/модульной. Вчера решил проверить так ли это на самом деле. Основным принципом модульной расширяемой системы является то, что она состоит из динамически {загружаемых, выгружаемых, линкуемых} модулей, причем каждый модуль может быть загружен и слинкован с остальными модулями, естественно, только один раз (зачем в модульной системе загружать и линковать 2 экземпляра одного и того же модуля???); а также то что она обладает одним единственным сборщиком мусора на всю систему.
Например, модуль M1:
MODULE M1

VAR X*: INTEGER;

END M1.

будучи один раз загруженным в память предоставляет переменную M1.X (в одном единственном экземпляре) всем остальным модулям всей модульной расширяемой операционной системы.

В .NET это не так!
Каждый якобы модуль системы .NET (будем писать его в кавычках: "модуль"), оказывается вовсе не является модулем всей системы .NET. А он является модулем лишь каждого конкретного приложения которое его импортировало. Сколько приложений импортировало этот "модуль" столько экземпляров его и будет создано.

Вот пример:
Исходный код "модуля" M1.dll:
namespace M1
{
    public class Var
    {
        public static int X;
    }
}

Исходный код "модуля" A1.exe:
namespace A1
{
    class Program
    {
        static void Main(string[] args)
        {
            M1.Var.X++;
            System.Console.WriteLine("M1.Var.X = {0}", M1.Var.X);
            System.Console.ReadLine();
        }
    }
}

Исходный код "модуля" A2.exe:
namespace A2
{
    class Program
    {
        static void Main(string[] args)
        {
            M1.Var.X++;
            System.Console.WriteLine("M1.Var.X = {0}", M1.Var.X);
            System.Console.ReadLine();
        }
    }
}

Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе.





Выводы
1) Сама .NET не является модульной системой. Модульной системой является каждое конкретное .NET приложение, в рамках которого модули загружены/слинкованы в единственном экземпляре.

2) Вот вам и объяснение того почему минимальные .NET приложения типа "Здравствуй Мир!" используют так много памяти (3.8 мегабайтов для минимального консольного и 8 мегабайтов для минимального оконного) — они просто содержат в себе копии всех системных/библиотечных модулей, чего не было бы если бы сама .NET была модульной! А что если системные/библиотечные модули будут требовать не 4-8 мегабайтов, а 100-200 мегабайтов? Расширяемой модульной системе это безразлично, так как она каждый модуль загружает лишь однажды, а .NET создаст их столько раз сколько приложений их использует!

3) Раз так, то, думается, что и сборщик мусора присутсвует в .NET не в единственном экземпляре (как это должно быть в модульной расширяемой системе), а опять же, во множественном.


11.12.04 02:01: Перенесено из 'Философия программирования'
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Flamer rsdnhttp://users.livejournal.com/_flamer_/
Дата: 02.12.04 08:21
Оценка:17 (6) +5 :)
Здравствуйте, Сергей Губанов, Вы писали:

[]

До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library.
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Mr. Nonehttp://mrnone.blogspot.com
Дата: 02.12.04 08:28
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе.


Вы бы хоть Дж. Рихтера на досуге почитали. Познали бы очень много относительно принципов работы Dynamic Link Library. Например, вот такое откровение:
1) любая dll разделяется всеми использующими её процессами, таким образом её код в физической памяти присутсвует в единственном экземпляре;
2) память, используемая dll для чтения и записи по-умолчанию управляется по принципу Copy-on-write, пока dll только читает из памяти, она (память) разделяется всеми процессами, как только dll пытается записать в память, процесс получает свою копию данных (НЕ КОДА DLL!!!);
3) если надо, то можно расшарить память dll между всеми процессами...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 08:31
Оценка: -8 :)
Здравствуйте, Flamer, Вы писали:

F>До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library.


Коротко, чтобы хватило сил дочитать:

В модульной расширяемой системе переменная M1.X существует в единственном экземпляре, в то время как в .NET экземпляров этой переменной будет столько сколько приложений, отсюда вывод — сама по себе .NET не является модульной расширяемой системой.

И где же бред?
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Mr. Nonehttp://mrnone.blogspot.com
Дата: 02.12.04 08:32
Оценка:1 (1) -2 :))) :))
Здравствуйте, Сергей Губанов, Вы писали:

Сударь, кончайте позорить нижегородцев регулярно неся какую-то околесицу на форуме! Я вам говорю это на тех правах, что я сам родился и вырос в Нижнем Новгороде, но волею судеб живу в Новосибирске...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[3]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Mr. Nonehttp://mrnone.blogspot.com
Дата: 02.12.04 08:34
Здравствуйте, Сергей Губанов, Вы писали:

F>>До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library.


СГ>Коротко, чтобы хватило сил дочитать:


СГ>В модульной расширяемой системе переменная M1.X существует в единственном экземпляре, в то время как в .NET экземпляров этой переменной будет столько сколько приложений, отсюда вывод — сама по себе .NET не является модульной расширяемой системой.


СГ>И где же бред?


В непонимании... можно сделать так, чтобы M1.X существовало в единственном экземпляре, но поскольку обычно это нафиг не нужно, по умолчанию сделано наоборот.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 08:36
Оценка: :))) :)
Здравствуйте, Mr. None, Вы писали:

MN> ...если надо, то можно расшарить память dll между всеми процессами...


Естественно надо! Почему же этого не сделано в .NET? Почему каждый экземпляр минимального оконного приложения отъедает по 8 мегабайтов памяти? Запустил десяток минимальных приложений "Зравстуй Мир!", а память то и кончилась...
Re[3]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Mr. Nonehttp://mrnone.blogspot.com
Дата: 02.12.04 08:39
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mr. None, Вы писали:


MN>> ...если надо, то можно расшарить память dll между всеми процессами...


СГ>Естественно надо! Почему же этого не сделано в .NET? Почему каждый экземпляр минимального оконного приложения отъедает по 8 мегабайтов памяти? Запустил десяток минимальных приложений "Зравстуй Мир!", а память то и кончилась...


Если вам это надо, то берёте и компилируете со специальными параметрами — какие навскидку не вспомню, потому что за всю мою практику мне это было нужно один раз — чисто из спортивного интереса. Если интересно почитайте в Рихтере что где и как надо выставить.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Lloyd 
Дата: 02.12.04 08:39
Оценка: :))) :))) :)))
Здравствуйте, Сергей Губанов, Вы писали:

Ты гений!!!
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 02.12.04 08:43
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

Бред.
Во-первых, физически DLL все-таки разделяются. Ты что думаешь, что каждый процесс в Windows держит свою отдельную копию kernel32.dll?
Во-вторых, нет никакой "всей системы .Net". Каждое приложение .Net и представляет собой независимую систему. И нет никакой причины критиковать такую организацию. Если я запущу несколько копий черного коробка на своей машине, то его модульность тоже станет шитой белыми нитками?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Kh_Oleghttp://kholeg.wordpress.com
Дата: 02.12.04 08:54
Оценка:19 (2) :))
Здравствуйте, Mr. None, Вы писали:

СГ>>Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе.


MN>Вы бы хоть Дж. Рихтера на досуге почитали. Познали бы очень много относительно принципов работы Dynamic Link Library. Например, вот такое откровение:

MN>1) любая dll разделяется всеми использующими её процессами, таким образом её код в физической памяти присутсвует в единственном экземпляре;
MN>2) память, используемая dll для чтения и записи по-умолчанию управляется по принципу Copy-on-write, пока dll только читает из памяти, она (память) разделяется всеми процессами, как только dll пытается записать в память, процесс получает свою копию данных (НЕ КОДА DLL!!!);
MN>3) если надо, то можно расшарить память dll между всеми процессами...

Принципы работы Dynamic Link Library здесь ни при чем. Сергей просто не понимает, что при старте каждого нового .NET приложения для него создается своя .NET Environment. Вот внутри нее и разделяются все сборки (но только для одного приложения ), один сборщик мусора. А для того, чтобы один сборщик мусора был на все запущенные .NET приложения и все сборки разделялись необходимо чтобы поддержка .NET была в самой операционной системе: общий Environment для всех приложений, сборщик мусора должен работать как системная служба и т.д. Но пока это не так. Очень вероятно, что в Longhorn'е все это уже будет присутствовать.

Так что это не .NET немодульная, а Windows.
Олег.
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 09:23
Здравствуйте, Sinclair, Вы писали:

S> ..нет никакой "всей системы .Net". Каждое приложение .Net и представляет собой независимую систему.


О как! Я всего лишь сказал, что сама система .Net не является расширяемой модульной системой, а оказывается она никакой не является потому что ее нет. Сурово, однако... На такой исход даже не расчитывал...
Re[3]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 09:28
Оценка: :)
Здравствуйте, Kh_Oleg, Вы писали:

K_O> Сергей просто не понимает, что при старте каждого нового .NET приложения для него создается своя .NET Environment.


K_O>Так что это не .NET немодульная, а Windows.


А, теперь ясно. Я-то думал .NET Environment сделана по взрослому — одна на всех, а оказывается у каждого своя...
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Glоbus 
Дата: 02.12.04 09:41
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Выводы

СГ>1) Сама .NET не является модульной системой. Модульной системой является каждое конкретное .NET приложение, в рамках которого модули загружены/слинкованы в единственном экземпляре.

Ну начнем с того, что нет никакой "самой .НЕТ". Каждое приложение запущенное под .нет имеет свою отдельную песочницу и само собой что между этими приложениями длл-на не разделяется по данным.
Но мне вот просто интересно как Компонентная Система Сергея Губанова отработала бы такую ситуаху. Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго?
Удачи тебе, браток!
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Mr. Nonehttp://mrnone.blogspot.com
Дата: 02.12.04 09:50
Оценка: :))) :))) :))
Здравствуйте, Glоbus, Вы писали:

G>Но мне вот просто интересно как Компонентная Система Сергея Губанова отработала бы такую ситуаху. Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго?


Да какая разница... Главное что это будет КОМПОНЕНТНЫЙ КОМПИЛЯТОР!!!
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[3]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 02.12.04 10:03
Оценка:17 (3) +3 :))
Здравствуйте, Сергей Губанов, Вы писали:
СГ>О как! Я всего лишь сказал, что сама система .Net не является расширяемой модульной системой, а оказывается она никакой не является потому что ее нет. Сурово, однако... На такой исход даже не расчитывал...
А на вопросы ты принципиально не отвечаешь? Где-то я таких видел... Ах, да! Ходют иногда по квартирам, предлагают поговорить о библии.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: a 
Дата: 02.12.04 10:04
Оценка:3 (1) :))) :))) :))) :))) :))) :))) :))) :))) :)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Никогда раньше не работал с .NET, но слышал что она является компонентной/модульной. Вчера решил проверить

В свою очередь, со всей ответственностью исследователя сферическо-кубических коней в вакууме и в прочих средах с нелинейными характеристиками, заявляю — не только компонентность .NET шита белыми нитками — но и факт существования меня с Вами — также является шитьём белыми нитками. А теперь, пожалуйста — пройдёмте в палату...
Re[2]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 10:09
Здравствуйте, Glоbus, Вы писали:

G> Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго?


DEFINITION Compillers;

TYPE
  Compiller = POINTER TO ABSTRACT RECORD
   (* ... *)
  END;
    
  Directory = POINTER TO ABSTRACT RECORD 
   (f: Directory) New (): Compiller, NEW, ABSTRACT;
   (* ... *)
  END;

VAR
  dir-: Directory;

END Compillers.

Переменная Compillers.dir — существует в единственном экземпляре (и доступна только для чтения "-") на всю модульную расширяемую операционную систему. Когда какому-то другому модулю понадобился еще один компилятор, то он делает так:
IMPORT Compillers;

VAR compiller: Compillers.Compiller;
BEGIN
  compiller := Compillers.dir.New();

compiller — локальная объектная переменная текущего модуля.

Переменная Compillers.dir играет роль фабрики объектов Compillers.Compiller.
Re[3]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Курилкаhttp://kirya.narod.ru/
Дата: 02.12.04 10:16
Здравствуйте, Сергей Губанов, Вы писали:

[skipped]

А на кой ляд программе знать что есть список компиляторов и создавать свой компилятор?
В чём крутость "единственности" этого списка?
Re[4]: Компонентность .NET шита белыми нитками в избранное  новое    модер. 
От: Сергей Губановhttp://sergey-gubanov.livejournal.com/
Дата: 02.12.04 10:29
Оценка: -1 :)
Здравствуйте, Курилка, Вы писали:

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


К>[skipped]


К>А на кой ляд программе знать что есть список компиляторов и создавать свой компилятор?

К>В чём крутость "единственности" этого списка?

Есть такой паттерн проектирования, Фабрика называется.

Например, есть участок кода, который хочет самостоятельно создавать объекты Compillers.Compiller в неограниченном количестве, но сам их делать не умеет, поэтому ему нужно дать фабрику
PROCEDURE P(dir: Compillers.Directory);

Но фабрику ему можно дать как стандартную
P(Compillers.dir);

так и самодельную
P(MyCompillers.myDir);

где MyCompillers.myDir — переменная типа являющегося расширением типа Compillers.Directory (то бишь класс-потомок).
1 2 3 4 5 6 7 8 9 10 1114