hrg>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). Быстро и hrg>безопасно.
Не, это вариант 3, просто парсеры языков подключаются динамически. Кстати, бесопасны не сами модули, а языки, ими поддерживаемые. Если будет косяк в самом модуле, апач рухнет вместе с ним. И на этих модулях бизнес-логика не реализуется.
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Вспомним историю развития средств: ЕК>1. CGI Хорошо, но медленно: для каждого клиента запускается отдельный процесс.
Старый офицер рассказывает курсантам:
-...Пуля, выпущенная из этого оружия, летит со скоростью 600 м/с
-Но это же медленно!
-Знаешь, я не видел, чтобы кто-нибудь бегал быстрее.
Вот другая реальность:
1. Свой веб-сервер, когда нужна действительно большая скорость.
2. Чужой веб-сервер и CGI-скрипты, dll-ки, когда скорость не нужна.
Евгений Коробко -> "Re[3]: C++ server pages, однако"
hrg>>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). hrg>>Быстро и hrg>>безопасно.
ЕК> Не, это вариант 3, просто парсеры языков подключаются динамически.
Странная квалификация. То сначала квалифицируется по способу обработки (CGI,
DLL), то по языкам.
mod_чегототам — это полноценная библиотека *.so. В которой, в том числе
может находится и парсер конкретного языка.
ЕК> Кстати, бесопасны не сами модули, а языки, ими поддерживаемые. Если ЕК> будет косяк в самом модуле, апач рухнет вместе с ним.
Рухнет поток. И все. Остальные будут работать как дальше. Апач просто
стартанет еще один поток. А то давно был полинтернета периодически лежало
из-за неохватного радиуса кривизны верхних хватательных конечностей
отдельных индивидов
ЕК> И на этих ЕК> модулях бизнес-логика не реализуется.
AndrewVK -> "Re[3]: C++ server pages, однако"
A> Здравствуйте, hrg, Вы писали:
hrg>>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). hrg>>Быстро и hrg>>безопасно.
A> В смысле? Если сам модуль, то он ничуть не безопаснее dll, если perl, A> phph, asp, то это п.3.
Модули для апача используют его интерфейс. API Acpahe. Работаю
как хандлеры событий, которые вызывает апач. Модули могут быть написаны на
чем угодно, начиная от С, заканчивая хз чем.
Теперь к скриптовым языкам. Вызов интерпретатора скриптого языка возможет
как через механизм CGI (запускается отдельный процесс с интерпретатором) а
также его разновидноестей, FastCGI. HeavyCGI; так через обработчика хандеров
(нативный хандлер на С, mod_perl и и.д.) Причем во втором случае мы получаем
контроль практически на любом этапе обработки запроса.
hrg>Странная квалификация. То сначала квалифицируется по способу обработки (CGI, hrg>DLL), то по языкам.
Квалифицируется по способу реализации бизнес-логики. Создание mod_... к бизнес-логике отношения не имеет.
hrg>Рухнет поток. И все. Остальные будут работать как дальше. Апач просто hrg>стартанет еще один поток.
Апач не на яве написан. Если модуль запашет память (которая общая для всех модулей и самого апача), то рухнет всё
hrg> а что же на них тогда реализуется ?
Здравствуйте, AndrewVK, Вы писали:
V>>насколько мне казалось, скриптовые языки отличаются своей интерпретируемостью.
[...]
AVK>Разницу между often и always ощущаешь?
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера
да ну?
вызов ф-ий DLL производится из некоей ф-ии обработчика запроса.
типа так:
void ProccessRequest(Request& rq, Response& rs) {
try {
// тут что-то происходит со страницами
} catch(...) {
Responce << UNDEFINED_APPLICATION_ERROR_HTML_TEXT;
}
}
Другое дело, что запуск в одном адресном пространствеможет что-то похерить в важных данных самого сервера...
но дык, это расплата за эффективность и прочие бенефиты.
Хотя, при желании можно прилично побороться и с такой проблемой. Например, выделить прикладным модулям свой heap в виртуальном адресном пространстве, которое с обоих сторон окружено "дырами" в виртуальной памяти. Тогда наиболее частые причины падения, типа переполнения стека и выход за границы массива будут что-то портить или в самом прикладном модуле, или натыкаться на несуществующую память и просто генерить эксепшн.
Евгений Коробко -> "Re[5]: C++ server pages, однако"
hrg>>Странная квалификация. То сначала квалифицируется по способу hrg>>обработки (CGI, hrg>>DLL), то по языкам.
ЕК> Квалифицируется по способу реализации бизнес-логики. Создание ЕК> mod_... к бизнес-логике отношения не имеет.
(задумчиво) дай, тогда пожалуйста тове видение реализации бизнес логики по
отношению к веб-серверу.
hrg>>Рухнет поток. И все. Остальные будут работать как дальше. Апач hrg>>просто hrg>>стартанет еще один поток.
:) Апач не на яве написан. Если модуль запашет память (которая общая для
::всех модулей и самого апача), то рухнет всё
AndrewVK -> "Re[5]: C++ server pages, однако"
hrg>>Рухнет поток. И все. Остальные будут работать как дальше.
A> А что, потоки у нас уже изолированы от общей памяти приложения?
Здравствуйте, hrg, Вы писали:
A>> А что, потоки у нас уже изолированы от общей памяти приложения?
hrg>http://httpd.apache.org/docs/misc/API.html#pools
hrg>Если писать хандлеры на mod_perl, то можно вообще забыть про эти проблемы
Здравствуйте, hrg, Вы писали:
A>> В смысле? Если сам модуль, то он ничуть не безопаснее dll, если perl, A>> phph, asp, то это п.3.
hrg>Модули для апача используют его интерфейс. hrg>API Acpahe. Работаю hrg>как хандлеры событий, которые вызывает апач. Модули могут быть написаны на hrg>чем угодно, начиная от С, заканчивая хз чем.
"Если сам модуль, то он ничуть не безопаснее dll" (С) я
hrg>Теперь к скриптовым языкам. Вызов интерпретатора скриптого языка возможет hrg>как через механизм CGI (запускается отдельный процесс с интерпретатором) а hrg>также его разновидноестей, FastCGI. HeavyCGI; так через обработчика хандеров hrg>(нативный хандлер на С, mod_perl и и.д.) Причем во втором случае мы получаем hrg>контроль практически на любом этапе обработки запроса.
AndrewVK -> "Re[7]: C++ server pages, однако"
A> Здравствуйте, hrg, Вы писали:
A>>> А что, потоки у нас уже изолированы от общей памяти приложения?
hrg>>http://httpd.apache.org/docs/misc/API.html#pools
hrg>>Если писать хандлеры на mod_perl, то можно вообще забыть про эти hrg>>проблемы
A> Это и будет п.3.
Это будет пункт 2 и 3, потому что будет возможнось управлять всем процессом
обработки запроса, тогда так п. 3 дает только возхможность обрабатывать
стадию отдачи контента
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
Здравствуйте, hrg, Вы писали:
A>> Это и будет п.3.
hrg>Это будет пункт 2 и 3, потому что будет возможнось управлять всем процессом
Не будет. Потому что механика модулей апача и механика скриптов конкретный модуле это две разные вещи. Никакой принцципиальной разницы между apache+mod_asp и iis+asp isapi нет.
AndrewVK -> "Re[9]: C++ server pages, однако"
A> Здравствуйте, hrg, Вы писали:
A>>> Это и будет п.3.
hrg>>Это будет пункт 2 и 3, потому что будет возможнось управлять всем hrg>>процессом
A> Не будет. Потому что механика модулей апача и механика скриптов A> конкретный модуле это две разные вещи. Никакой принцципиальной A> разницы между apache+mod_asp и iis+asp isapi нет.
будет. Как ты на asp напишешь обработку фазы аутентификации? Поэтому я
говорю — что это смесь типов 2 и 3.
Здравствуйте, Евгений Коробко, Вы писали:
ГВ>>От кривизны рук всегда защититься сложно. Что поделаешь... Значит, просто требования к квалификации разработчиков должны быть выше. ЕК>Ага, с таким же успехом можно допустить, чтобы ОС падала при AV в программе и разводит руками: нужно программы грамотно писать.
А что? Их писать грамотно не нужно?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Думается, что основная причина — это отсутствие необходимости.
А нужно ли? ИМХО подавляющее большинство задач на Web решается существующими средствами и притягивать C++ просто нет необходимости, за исключением специфических задач.
а что же на них тогда реализуется ? 
