Inktomi Traffic Server на Linux

Bye, bye squid, oops. Никто из них не смог даже приблизиться к Inktomi.

Бай Бай не будет Платное это все

Если бы ты был провайдером, то заплатил бы любые деньги, чтоб только не трахаться с дерьмом по фамилии сквид и иже с ним. Дешевле получается ;-(

1. Что имеется ввиду под BSD+Linuxthreads - IMHO, Linuxthreads давно переродились в очень крутые posix threads под BSD. 2. А чем плох squid? А delegate не пробовали?

1. И чем так уж хорош этот "Inktomi Traffic Server"?
Tima_, anonymous вы его пробовали?
2. К Shadow - давно, это с 4.xx?

Я думаю надо сообщить общественности факты:
a) Linuxthreads никуда не перерождались на FreeBSD. Linuxthreads были
портированы один к одному из Linux с тем только различием, что вместо
системного вызова clone используется BSD аналог rfork, а вместо GLIBC
используется библиотека, по сути являющаяся libc_r минус userland
sheduler. На сегоднящий день использование этой библитеки - это
единственный способ написания программ, способных воспользоваться
наличием более чем одного процессора в системе, чем, вероятно, и
объясняется выбор Inktomi. Недостатком является то, что threads в
LinuxThreads являются процессами и потому пожирают довольно много ресурсов
в адресном пространстве кернела и требуют довольно дорогостоящих системных
вызовов при context switch'е.

b) Реализация threads в libc_r - это достаточно полная реализация POSIX
pthreads API, реализованная целиком и полностью в userland'е без
какой-либо помощи со стороны ядра. Эта реализация страдает всеми
недостатками, обычно ассоциирующимися с подобными архитектурами, однако
эти недостатки в значительной мере смягчены эффективной реализацией
non-blocking IO во FreeBSD. Относительным достоинством реализации
является очень и очень незначительная стоимость переключения между
контекстами различных цепочек по сравнению с той же операцией в
Linuxthreads. Непосредственно перед выходом 4.2-RELEASE некий deishen
ускорил это дело примерно в 10 раз, полностью устранив необходимость
каких-либо системных вызовов при переключении, эффективно сделав его
сравнимым по скорости с обычным вызовом функции (на FreeBSD mailing list-ах
приводились примеры, где context switch на FreeBSD разотал в десятки, если
не в сотни раз быстрее, чем в Linux). При всей своей продвинутости,
системные threads во FreeBSD всё равно никоим не способны скалироваться на
несколько процессоров, и это их фатальный недостаток.

с) Всё вышесказанное привело к тому, что FreeBSD проект посчитал абсолютно
необходимым создание совершенно новой архитектуры для поддержки multithreaded
программ, которая совмещала бы в себе преимущества _обоих_ подходов.
Эта архитектура известна под названием scheduler activations и её описание
легко находится на Internet. В общем и целом, это очень похоже на то, что
имеется в Solaris, которая, IMHO, имеет лучшую threads реализацию на
сегодняшний день. Новые threads должны появиться во FreeBSD 5.0, которая
должна выйти где-то летом 2000-го года.

Надеюсь, я ничего не пропустил :)

Лето 2000-го уже прошло ;) Или ты кого-то дословно цитируешь?
Мне, как программисту, перешедшему из Windows во FreeBSD, было не сразу
понятно, почему юзают fork, а не pthreads. Ну я и писал свои первые демоны
на pthreads + мютексы

А может быть объяснишь, почему надо юзать fork, а не pthreads? Что-то я не понял...

Я не утверждал, что надо юзать fork.
По виндовой привычке я больше юзаю нити, а не процессы.