да стопудово в библиотеке, сейчас будем переходить на upstream версию
писали, но похоже не туда
единственная и самая лучшая книга
http://www.rubycentral.com/book/index.html
POSIX Threads, sockets и prefork model. Простой пример.
-
- Интересующийся
- Сообщения: 65
- Зарегистрирован: 19 авг 2003, 10:56
- Откуда: Anwerpen, Belgium / Belarus
- Контактная информация:
2 Гость: Это поддержка более строгой типизации добралась и до C.
2 [uNIx]mend0za:
Я тут как-то наткнулся на описание следующей существовавшей проблемы с accept(). Описывается она для ядра 2.2.* - 2.3.*. Надо полагать исправлена в 2.4.
Так вот поведение ядра не совсем то что я предполагал и скажем нелогично/неэффективно - оказывается пробуждались все ожидающие потоки/процессы, правда только на уровне исполнения кода в режиме ядра, затем только один продолжал выполнение с новым соединением - возврат в пользовательский режим, остальные возвращались в спящее состояние. С точки зрения пользователя - просыпался только один, но со стороны ядра было лишняя трата времени на исполнение кода в режиме ядра.
В общем тут более подробное описание, если интересно:
http://www.citi.umich.edu/projects/linu ... ccept.html
На счет потоков на пользовательском уровне - была тут идея у меня скомбинировать принятие соединений на базе потоков ядра (pthread - которая использует эту модель 1:1), а обработку запросов на базе какой-либо библиотеки потоков пользовательского уровня. На первый взгляд кажется эффективным если большая часть (а лучше почти вся) обработки запроса идет в пользовательском режиме, т.е. нет/немного блокирующих вызовов (хотя пожалуй и это можно частично решить). В этом случае, если есть много обрабатываемых в одно и то же время запросов такого рода - то можно выиграть за счет меньшего времени переключения контекстов потоков на пользовательском уровне.
2 [uNIx]mend0za:
Я тут как-то наткнулся на описание следующей существовавшей проблемы с accept(). Описывается она для ядра 2.2.* - 2.3.*. Надо полагать исправлена в 2.4.
Так вот поведение ядра не совсем то что я предполагал и скажем нелогично/неэффективно - оказывается пробуждались все ожидающие потоки/процессы, правда только на уровне исполнения кода в режиме ядра, затем только один продолжал выполнение с новым соединением - возврат в пользовательский режим, остальные возвращались в спящее состояние. С точки зрения пользователя - просыпался только один, но со стороны ядра было лишняя трата времени на исполнение кода в режиме ядра.
В общем тут более подробное описание, если интересно:
http://www.citi.umich.edu/projects/linu ... ccept.html
На счет потоков на пользовательском уровне - была тут идея у меня скомбинировать принятие соединений на базе потоков ядра (pthread - которая использует эту модель 1:1), а обработку запросов на базе какой-либо библиотеки потоков пользовательского уровня. На первый взгляд кажется эффективным если большая часть (а лучше почти вся) обработки запроса идет в пользовательском режиме, т.е. нет/немного блокирующих вызовов (хотя пожалуй и это можно частично решить). В этом случае, если есть много обрабатываемых в одно и то же время запросов такого рода - то можно выиграть за счет меньшего времени переключения контекстов потоков на пользовательском уровне.