Вообще, название темы довольно неграмотное. Точнее было бы её назвать - "нужна ли вытесняющая многозадачность?".

Вытесняющая многозадачность например совсем не нужна вот в этом случае:
> -- Valery Solovey писал(а):
> Один поток будет тормозить весь сервер, если он будет блокироваться на вводе-выводе (жёсткий диск, сеть, IPC, другие устройства).
Просто потому, что никто не отменял неблокирующую, асинхронную, работу с сетью, IPC и так далее. Это есть везде. Поэтому обычному скажем веб-серверу вытесняющая многозадачность нафиг не уперлась.

Но представим что у нас не просто веб-сервер, у нас, скажем, сервер видеоконференций. (и пусть у него, чтобы пример был ярче, всего один процессор с одним ядром, так что многопоточность нам тут скорости не прибавит). Он не просто байтики перекладывает, но над полученными байтиками он производить сложные и длительные математические вычисления (кодирование/декодирование h264/h265, всякие фильтры и так далее). На очередную порцию байтиков может действительно уйти МНОГО времени - до одной секунды (ключевой кадр например). И, что важнее - прервать эту операцию на середине, и передать управление другому коду в случае кооперативной (не вытесняющей) многозадачности просто невозможно (если у нас математический код не спец. компилятором собран, который навтыкает счетчиков да yield'ов, тем самым СИЛЬНО (в 4-10 раз) снизив производительность на современном x86 (из за условных переходов предсказатель переходов начнет ошибаться)). Следовательно вызов такой вот математики - блокирующий. А мы не имеем права уходить в себя на целую секунду - jitter buffer обычно настроен на 200ms максимум, нельзя чтобы другие клиенты страдали. У нас реалтайм. Поэтому в этом классе задач вытесняющая многозадачность нужна.

Теперь вопрос в том - потоки, или процессы? Увы, но множество процессов тоже не годится - объем передаваемых данных велик, поэтому накладные расходы на IPC будут слишком велики (причем как на передачу данных так и на примитивы синхронизации). Плодить по процессу на каждую конференцию или  на каждого клиента - также слишком затратно.

Поэтому тот код который занимается сингналингом и транспортом - живет в одном потоке и обрабатывает множество клиентов через асинхронных не блокирующий ввод-вывод (для пущего удобства можно использовать fiber'ы), а вот математика/енкодеры/декодеры живут в собственных потоках либо потоке. И все это вместе живет в общем процессе.