нет ;)
linux/list.h - это часть ядра со всеми вытекающими

вот адаптированная для userspace имплементация


Присоединённый файл ( Кол-во скачиваний: 5 )
 list.rar 2,87 Kb

MAKCim, Скажите, можно ли как-то определить кол-во процессоров/ядер?

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

но это не сецифицировано в posix

Могу высказать свое скромное мнение по этому поводу.

Возможно подойдет архитектура nginx.
1 главный процесс и несколько рабочих процессов (или потоков).

Главный процесс принимает новое соединение и передают его одному из рабочих (в случае использования потоков это логично делать через глобальные структуры данных, например списки списков, при использовании дочерних процессов скорее подойдет дублирование дескрипторов и именованные каналы).

Каждый из рабочих процессов работает с несколькими клиентами. В этом случае наиболее удачным по производительности решением будет использование мультиплексирования на основе poll или pselect (если разработка ведется под конкретных платформу, то лучше применять специализированные методы Linux - epoll, FreeBSD - kqueue).

Остается логичный вопрос по поводу количества рабочих процессов, но на мой взгляд формула: кол-во ядер CPU == кол-ву рабочих процессов, не очень удачна, поскольку не учитывает блокировки процессов при файловом вводе-выводе. 
Точное количество конечно надо определять экспериментально, поэтому этот параметр должен задаваться извне, а не быть зашитым в программу.

тогда уж лучше юзать libevent и забыть о select/poll/epoll/kqueue/... ;)

Дык..
Я пишу, используя epoll, а выясняется что лучше libevent. Так что мне использовать?

niXman
libevent кроссплатформенная библиотека
если нужна кроссплатформенность, лучше использовать ее, т. к. select и poll не столь эффективны
это не более чем комментарий к посту sdukshis

MAKCim, Да, я уже посмотрел. Это просто обертка над API функциями.
Продолжаю кодить...

Добавлено через 2 минуты и 38 секунд
Да, кстати. Провел эксперимент по распределению потоков на ядра. Все правильно, если создать 4 потока, то ОС правильно распределит, по одному на ядро.

А есть ли резон писать свою сетевую часть? Советую обратить взор на boost::asio (и на boost::thread к слову о потоках и количестве ядер, там есть специальня функция, говорящая сколько потоков можно эффективно заюзать)

В доках boost'а есть хороший мануал, что с этой библиотекой делать, и как это делать эффективно.

Я не пишу подсистему ввода-вывода. Прочитайте второй пост.

Не хочу использовать по некоторым причинам.

Можно по подробнее? Интересно взглянуть на реализацию.

Это сообщение отредактировал(а) niXman - 20.10.2009, 19:05

 Сомневаюсь, что у него будет количество пользователей ) В разы меньше будет.
Тем более что если пользователем будет запрошено ресурсоемкое действие, это заморозит всех пользователей на этом же потоке.

это смотря какие руки и голова ;)

MAKCim, и как можно этого избежать?

Присоединяюсь.

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