> на серверсайде тредов вообще быть не должнообоснуй. я серьезно спрашиваю
> треды - легкие процессы, живущие в одном процессе в его хипе и стеке, за ними ос вообще не следит как за процессами по таблице процессов. отлаживать такое говно невозможно, как и наращивать.за счет этого как раз и достигается профит - они юзают одну и ту же память
> промышленное использование тредов на серверсайде есть только у:
mysql, какое это говно - знают все.
java апликухи типа томкатов или веб сфер, но там жаве везет, т.к. по протоколу http 1.1 рано или поздно коннект отвалится и тред уничтожается, иначе падение неминуемо.
треды - срество для дебилов, которые не могут простой манагер памяти сделать в шареной памяти. взять ipc реализации серверсайда - это оракл, постгрес, информикс и т.д. и т.п. - абсолютно стабильные серверные решения.
вечером опишу почему треды на серверсайде противопоказаны, опишу почему те, кто их юзает на серверсайде - идиоты ленивые, которые привыкли с кучей работать через нью делит, а на менеджер памяти простенький мозгов не хватает.
треды с мьютексами на то и легкие процессы, чтобы запускаться на пару сотых секунды и пропадать. у меня к примеру в серверном фреймворке вообще нет
операций new он же alloc, т.к. при старте отхавал гигов десять шареной памяти,
и конкурентный доступ через семафоры. на весь фреймворк хватает одного массива семафоров с количеством в нем 9 штук. и всех делов
вообще все нормальные серверные решения сводятся к очень ограниченному объему:
надо быстро сделать говна кусок и веб - apache + mod_php,
так пхпистов развелось за 10 лет дох*я и готовы работать за еду.
надо что-то мощное и на нагрузках - c++ + libs + ipcs.
надо базы данных и есть бабло - оракл, лучшая платная реляционная дб.
бабла нету - постгрес, лучшая бесплатная.
все остальные жавы, питоны, отмиращий перл, руби, и прочие байтмашины
и говнотехнологии типа xml с еб*нутыми xslt и расширениями - оцтой и говно.
95% серверного инструментария и технологий можно смело на помойку унести.Дальше были простыни цыфр и мата
они созданы для раздувания интернет и вообще айти пузыря.
Надо много подумать
Походу понесло чела
ОтветитьУдалитьпричём здесь XML и XSLT :-) ?
походу интересно насчет ipc. Я вот сейчас вынужден для hpc двигаться в сторону процессов - так это ж костыли на костылях. 80% говнокода содержит указатели - оно без мата в шареную память просто не лезет.
ОтветитьУдалитьТо есть возникает наоборот впечатление - один раз написать что-то реэнтерабельное и юзать потоки из пула с возвратом в пул при проблемах и горя не знать. Ну и мне не только линукс а кроссплатформа.
Интересно подискутировать :)
автор исходных высказываний обещал смотреть что тут происходит в комментах - возможно он сам вам ответит
ОтветитьУдалитьвообще же в исходном посте шла речь про написание нового приложения (к сожалению это неочевидно из контекста). Для legacy code все вышесказанное может быть неверно. Пул потоков (под windows оно называется work queue - см. например http://blogs.msdn.com/b/larryosterman/archive/2004/03/29/101329.aspx?PageIndex=1) - вполне рабочий хак по моему чтобы быстро научить старую прогу работать на нескольких камнях. Но как справедливо было замечено - отладка этого счастья может быстро превратиться в кошмар
хе-хе есть такая работа - писать легаси код (новый) :D
ОтветитьУдалитьУ меня выбор - или потоки и правка расчетной части или процессы и запихивание в шареную память in-memory db. Просто потому что я больше знаю про устройство db я двигаюсь в сторону процессов. Ну прямо скажу - первые впечатления от процессов - эти костыли нужно будет таки выкинуть ради перформанса. Специфика отрасли - надо очень быстро считать кучу проверок над 2д геометрией. То есть клиенты довольны когда с разумным железом оно считается пару часов а не неделю как в однопоточке.
Ну и кто сказал что отлаживать процессы проще? для этого надо в них иметь железобетонные точки засыпания - чтобы можно было успеть создать новый процесс отладки и прицепиться к. Даже если мне удастся сделать общую память только на чтение то не факт что с синхронизацией и файлами не будет лажи.