Блокируемый ввод/вывод в многопоточном сервере

неправильно думаеш
при поступлении данных с сетевой - они на этом же процессоре - пошлються в буффер сокета -и на этом же процессоре пробудят нужный процесс который и заберет данные

если проц будет занят - то данные получаться по шедуллеру

Поток на блокирующем read будет спать до тех пор, пока не появятся данные, или вызов не будет прерван сигналом (получим EINVAL)

переключаться чтобы ждать? ЛОЛШТО?

при preemptive multitasking ос переключается между всеми потоками и процессами постоянно, выделяя каждому время для работы. что делает поток ОС не волнует.
время, выделяемое ОС зависит от приоритета котока.

кури операционные системы.

при preemptive multitasking ос переключается между всеми потоками и процессами постоянно

Если задача выполняет блокирующее I/O, ждёт сигнала или делает sleep, то переключения на такую задачу не делается (пока данные не будут получены, сигнал не поступит, или время sleep не истечёт), а timeslice не расходуется.

Тред полон наркоманов. Во-первых, не стоит уповать на то, как идут данные — с равными промежутками, хаотически или сплошным потоком. Во-вторых, делать многопоточный сервер таким способом (один поток — один сокет — один read()) — неправильно. man select, epoll, aio. В третьих, поток пробуждается из спячки по событиям, а не просто так. Одно из таки событий — приход данных в буфер сокета, на котором поток висит в read()'е.Система не дергает спящие потоки для того, чтобы они сами проверили, есть ли данные в сокете, т.к. это маразм.

А можно ли в lInux на С делать подобие пула потоков? Например, для каждого принятого куска данных при мультиплексировании ввода/вывода создавать поток и передавать ему данные на обработку. Или накладные расходы на создания потоков будут большими? Какие вообще паттерны применимы для моей задачи?

hint: никто не заставляет тебя создавать поток каждый раз, как появляются данные. Собственно, понятие «пул» это и подразумевает. О твоей задаче я не слова не услышал, только о мытарствах с потоками и read(), но, судя по твоим вопросам, могу только посоветовать делать все проще и не заморачиваться с потоками вообще.

Можно, но создавать поток для обработки каждого принятого куска не стоит

нифига себе, в ту же секунду ответили

блин, фейл

Так а как тогда делать?
Задача такая: есть долгоживущие TCP-соединения и от них с разной периодичностью приходят данные (примерно раз в секунду), которые нужно разбирать и класть в БД.

Диспатчить данные в потоки-воркеры для обработки. Поток выбирать исходя из загруженности его входящей очереди. В чём проблема-то?

раз в секунду

Нужна ли здесь многопоточность вообще? Пусть данные себе скапливаются в буферах сокетов, пока ты с БД возишься.

Во-вторых, делать многопоточный сервер таким способом (один поток — один сокет — один read()) — неправильно. man select, epoll, aio

Не неправильно, а нецелесообразно при определенных условиях (c10k очень чешется, например). Если подключений немного - можно делать и таким способом. (Среди реализаций проксей, например, вообще встречается поддержка многопроцессности/многопоточности/асинхронности в зависимости от флагов конпеляции в расчете на некоторую заданную пиковую нагрузку (не считая обратной совместимости))