softwarer c127А Почему на .НЕТ-е они "больше не будут такими опасными"? А какими опасными они были, до сих пор?
Я бы спросил, по сравнению с чем.

А я так и спросил:А Почему на .НЕТ-е они "больше не будут такими опасными ".

softwarer
Если я правильно понимаю смысл слов in-process, .NET-хранимки будут падать вместе с сервером.

Или сервер вместе с сохраненками.



MasterZiv
"extended процедуры" -- специальным образом оформленные модули, использующие специальное API и написанные как правило на С или С++.
Работают они в MSSQL (если еще ничего не поманяли в MS) в адресном пространстве самого сервера базы данных, т.е. это - .dll , подключаемые к процессу сервера. Нужно ли говорить еще что-то об их потенциальной "опасности" ?

Да, согласен. А что, .НЕТ extended процедуры будут работать как-то по-другому? Наверняка тоже в том же пространстве.

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

MoonLight c127Да, действительно, ошибся. Все время забываю что имею дело со сторонником мелкософта,...Смотря со стороны, хочется сказать: Удивительно, мы все забываем, что имеем дело с яростными противниками MS. Причем, действительно, создается такое ощущение, что очередной выход хорошего продукта от MS вызывает у них такие вопли, как буд-то бы им прищемили "причинные места" в дверях


Пардон, Вы необъективны. Эти вопли раздаются из лагеря мелкософта. Причем уже дошло до того, что их вызывает даже не выход продукта, а только ожидание выхода, поскольку сам выход многократно откладывается.

Чтоб не быть голословным, самый первый пост топика под названием " Весомый плюс Юкон над ORACLE ":
StalkerS> В Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET ......
/topic/143322&pg=1&hl=execute


SergSuper c127
Сторонники пошарпанного С утверждают, что их код компилируется в машинные коды и потому быстрый. Но в таком случае при выполнении на сервере он так же опасен, как С код из extended процедуры, там такие же указатели и прямой доступ к памяти. А если он в этом случае не будет компилироваться в машинные коды, то врядли получится выигрыш в скорости в сравнении с обычными сохраненками, который так пропагандирует Dooma.

Нет, .НЕТ процедуры компилируются в машинные коды и тем не менее они безопасные. Это потому что сначала они компилируются в промежуточный код, где опасные операции уже быть не могут - прямого доступа к памяти там быть не может.

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

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

Код будет относительно безопасным, если будет работать в виртуальной машине, тогда сломать он сможет только эту машину. Но тогда он не будет таким быстрым. Как ни крути, а чем-то прийдется пожервовать.

К тому же тут где-то утверждалось, что C# код транслируется именно в машинные коды и работает без виртуальной машины, не могу найти где. Но это в обычном приложении, на СКЛ сервере может быть по-другому.

SergSuper
На самом деле вещь то хорошая(я про .НЕТ), спорить тут нечего, но не сильно необходимая для сервера.

Именно это я и говорю, на сервере оно мало кому нужно. А энергии на интегрирование .НЕТ-а в СКЛ сервер потрачено немеряно и шума развели много. ИМХО не оправдывает затрат, лучше бы Т-СКЛ довели до ума.

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

но я не настолько знаю .Нет чтобы чего-то объяснять :)

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

SergSuperда нет в безопасном коде вообще указателей
а виртуальной машины в .Нет-е вообще нет - исполняется машинный код

ну почитал бы чего прежде чем выводы делать

Может Вы все-таки обратите внимание на то, что я никаких выводов пока не делаю, я делаю утверждения. В какой же части мои утверждения не верны? В том что "Безопасные указатели замедлят выполнение, их же каждый раз нужно проверять"? Вроде все правильно, действительно, чтобы код был безопасным компилятор должен встраивать код, который проверяет указатели каждый раз при их использовании и это замедляет работу. Или может я ошибся во второй части: "Либо же, выполнять код в виртуальной машине, тогда указатели будут указывать на виртуальную память и в случае чего испортят только ее"? Но вроде и тут все правильно, виртуальная машина действительно безопаснее, но замедляет выполнение кода. Или по-Вашему она его ускояет?

Кстати обращение к элементу массива по индексу тоже требует проверки на выход за пределы массива. Если хотите строить безопасный код то это тоже нужно проверять каждый раз когда используются индексы. Работу программы не ускоряет.

Или массивов в безопасном коде тоже нет?



ASCRUSВыполняет ... но только один раз. Далее, пока файлы сборки не изменяются, выполняются сами уже откомпилированные сборкой dll-ы, лежащие в кэше. Отсюда я в первых версиях VS.NET и видел забавный глюк, когда изменишь формочку, скомпилишь и запустишь проект, а запускается старая, неизмененная версия формочки.

Когда код в системе сам по себе это понятно. Вопрос в том, что происходит когда код компилируется в МССКЛ сервере, или для работы в МССКЛ сервере, не знаю как правильно.

Мы же вроде обсуждаем МССКЛ серверные сохраненки на .НЕТ-е, типа замена T-SQL, а оппоненты все норовят подсунуть ссылки на то, как работает независимое приложение. Подкиньте ссылку на .НЕТ в юконе.

gybsonc127, скажите, как можно рассуждать о .Net не имея ни малейшего, даже приблизительного, понятия о том, как это работает?

Ваш вопрос поставлен неверно, все-таки кое-какое представление о работе .НЕТ-а я имею. Тем более что я пытаюсь разобраться в работе .НЕТ-а, а в работе .НЕТ-а в МССКЛ сервере и подчеркиваю это уже не в первый раз.

Отвечаю на вопрос. Есть много способов. Из общих соображений, например. Ничего нарушающего общие и даже не очень общие представления там вроде не наблюдается. Или Вы не согласны?


Я уже третий день прошу ссылки на то, как работает .НЕТ в МССКЛ сервере. Может Вы нарушите добрую традицию молчания и выложите ссылку на то, как он работает. Либо расскажите сами.

SergSuper
Возможно что у меня не совсем верное представление что такое "виртуальная машина". Мне это представлялось как нечто выполняющее промежуточный байт-код. А на самом деле это что?

По-моему не обязательно. Это может быть настоящий исполняемый код, тот же x386, но выполняемый не на реальном процессоре/памяти, а на сэмулированных в другой программе. Например эмулятор палма и VMWare это виртуальные машины.

Т.е. виртуальная машина это программа или часть программы, изображающая из себя компьютер с процессором, памятью и периферией. ИМХО.

SergSuper
Не обязательно. Есть исключения процессора при обращении к запрещенной памяти, проверки делаются аппаратно и ничего не замедляют. Но как сделано в Нет-е - не знаю

Я тоже не знаю. Но в принципе согласен, такое может быть. Но в таком случае при работе внешней процедуры (extended procedure в терминологии Dooma), написанной на С тоже нет никакой опасности. Аппаратные ограничения памяти позаботятся о том, чтобы процедура не испортила память СКЛ сервера и системы. В этом случае непонятно почему процедуры на C# будут безопаснее чем на чем-то другом. (Dooma>Кроме того они больше не будут такими "опасными". /topic/231053&pg=3#2061467 )


SergSuper
Интересно, а кто сейчас работает с реальной памятью? Я последний раз в ДОСе, Win 3.11 на 286 процессоре уже с виртуальной памятью работала.

Но синий экран иногда выскакивает, хоть и редко. Значит кто-то все-таки работает.


SergSuper
Или массивов в безопасном коде тоже нет?

Вот нашел
Указатели и управление памятью. В языке C++ работа с указателями занимает одно из центральных мест. Нормальный стиль программирования на C# предполагает написание безопасного кода, а это значит - никаких указателей, никакой адресной арифметики, никакого управления распределением памяти.
Возможность работы с указателями в духе C++ ограничена "небезопасными" блоками. Небезопасный код для C# программистов будет скорее исключением, чем правилом.

Всякое исключение можно сделать правилом, как это случилось в С++ по-моему. Там работа с указателями тоже должна была стать (как я понимаю) исключением, но программисты это сделали правилом. Единственный способ этого избежать - не давать возможность делать исключения. Поэтому если в C# есть возможность добраться до указателей, то эта возможность будет использоваться.

SergSuper
Массивы. В языке C# появилась возможность объявлять классические многомерные массивы. Работа с массивами в C# более безопасна, поскольку контролируется выход за границы массива.

Не верю что это можно сделать без потери производительности. Подумайте сами, при каждом обращении к элементу массива нужно проверить if(i>=first_index && i<=last_index). Паскаль не аргумент, борландовские компиляторы традиционно плохо оптимизируют код, на фоне плохого кода проверка на выход из паскалевского массива может быть незаметна.

Но в принципе согласен. Если (!) extended procedures МССКЛ сервера на .НЕТ-е действительно компилируются в машинные коды, то они скорее всего будут работать быстрее Т-СКЛ-евских процедур.

Осталось выяснить куда именно они компилятся НА МССКЛ СЕРВЕРЕ, а не в случае отдельного приложения.


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

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