Могопоточное приложение на C++

[kzv]

один рабочий процесс nginx обслуживает множество подключений одновременно,

Правильно

а в апаче только одно,

Правильно

и если nginx будет использовать классические потоки (то же самое что threads в винде), с точки зрения производительности не изменится абсолютно ничего

Если нам договориться между собой тут, что потоки и процессы это одно и тоже, то для nginx очевидно ничего не поменяется ни в плане производительности, ни в каком другом плане. С чего бы вдруг?
Что-то поменяется если вы вместо асинхронной однопоточной работы начнете внутри процесса nginx плодить потоки для каждого сокета как это сделано в апаче. Вот тогда и увидите ад как он есть!

Остался еще один шаг: что по вашему делает "мастер процесс"?

Если говорить про сеть, то раньше он висел на приеме входящих соединений, с появлением опции reuseport это тоже переехало в worker-ы, так что теперь мастер просто читает конфиг и управляет worker-ами.

Ну вот мы еще раз убеждаетмся, что "потоки" в nginx это никакие не потоки, а самые настоящие процессы. Каждый "поток" это отдельный самостоятельный экземпляр сервера. Вся "многопоточность" нгинкса заключается в клонировании единственного однопоточного процесса.
То есть если на примере стартового поста темы, то автору многопоточность в стиле nginx можно организовать очень просто: достаточно сказать слушающему сокету "O_REUSEPORT" и запустить несколько экземпляров демона коина.

Можно... Если хотите чтобы все встало колом из-за ваших потоков и опросов

Это с каких пор epoll колом встает из-за его вызова из нескольких потоков? Может тесты какие подтверждающие есть? Это у kqueue такие проблемы есть и там рекомендуют использовать несколько независимых экземпляров для цикла сообщений, а у epoll и виндового iocp всегда все ок с этим было.

Мы обсуждаем сферического коня какого-то. Давайте ваш многопоточный сервер уже посмотрим.

Но ничто не мешает асинхронному приложению быть многопоточным

Если договориться, что потоки и процессы это одно и тоже, то конечно.

[1713876036]

1713876036

[1713876036]

1713876036

[1713876036]

1713876036

[Balthazar]

К счастью у меня нет готового примера, хотя... Можно глянуть на разработчиков апача наверное.

Разработчики Microsoft IIS, и даже получилось неплохо. Правда, там в центре вселенной драйвер http.sys, который в режиме ядра работает, т.е. вообще вся работа вебсервера с сокетами и большая часть i/o обходятся без переключений контекста, что немного жульничество.

Решили вопрос в лоб, так сказать.

P.S. Результаты не сферические, говорю как тот кто с IIS и nginx достаточно большое время просовокуплялся.

[Vadi2323]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

Почему же, при работе, например, с сетями многопоточность рулит. То ли последовательно обрабатывать 100 подключений за 100 раз (соединение, запрос, запись ответа, рассоединение, следующий узел пока до сотого не дойдём), то ли многопоточно 100 соединений за 1 раз (запуск сразу 100 потоков, соединение, ...., рассоединение, готово!). Причём многопоточность будет выигрывать тем раз больше, чем больше количество подключений нужно обработать. А если учесть затупы связи, то это уже не преимущество даже, а необходимость.

[Balthazar]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

Почему же, при работе, например, с сетями многопоточность рулит. То ли последовательно обрабатывать 100 подключений за 100 раз (соединение, запрос, запись ответа, рассоединение, следующий узел пока до сотого не дойдём), то ли многопоточно 100 соединений за 1 раз (запуск сразу 100 потоков, соединение, ...., рассоединение, готово!). Причём многопоточность будет выигрывать тем раз больше, чем больше количество подключений нужно обработать. А если учесть затупы связи, то это уже не преимущество даже, а необходимость.

Всё описанное не имеет никакого отношения к многопоточности и прекрасно работает в одном потоке.
Если кому-то из программистов для такого необходима многопоточность, то ему показана хирургическая коррекция расположения рук.

[kzv]

Почему же, при работе, например, с сетями многопоточность рулит. То ли последовательно обрабатывать 100 подключений за 100 раз (соединение, запрос, запись ответа, рассоединение, следующий узел пока до сотого не дойдём), то ли многопоточно 100 соединений за 1 раз (запуск сразу 100 потоков, соединение, ...., рассоединение, готово!). Причём многопоточность будет выигрывать тем раз больше, чем больше количество подключений нужно обработать. А если учесть затупы связи, то это уже не преимущество даже, а необходимость.

Как я уже пару раз тут говорил: сервер это одна из очень немногих специфичных задач, которая легко распараллеливается. В большинстве реальных задач распараллеливание невозможно.
Конкретно касаемо сервера, как я уже тут упоминал, имеет практический смысл делать число потоков не более чем есть ядер в процессоре. Если количество потоков будет больше, то параллельность будет сугубо мнимой. Чудес не бывает.
Все это касается случая когда поток это поток, а не процесс. Процессы можно раскидать не только по ядрам одного процессора, но и по нескольким отдельным процессорам и/или по нескольким отдельным машинам.

[Vadi2323]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

Почему же, при работе, например, с сетями многопоточность рулит. То ли последовательно обрабатывать 100 подключений за 100 раз (соединение, запрос, запись ответа, рассоединение, следующий узел пока до сотого не дойдём), то ли многопоточно 100 соединений за 1 раз (запуск сразу 100 потоков, соединение, ...., рассоединение, готово!). Причём многопоточность будет выигрывать тем раз больше, чем больше количество подключений нужно обработать. А если учесть затупы связи, то это уже не преимущество даже, а необходимость.

Всё описанное не имеет никакого отношения к многопоточности и прекрасно работает в одном потоке.
Если кому-то из программистов для такого необходима многопоточность, то ему показана хирургическая коррекция расположения рук.

[_IMG]https://img.techpowerup.org/200214/8579688.jpg[/img]

100 узлов. Допустим, на соединение с узлом и скачивание тратится 15 минут. В одном потоке обработать 100 узлов займёт 25 часов. В 100 потоках 15 минут.

Или 200 узлов. В данном случае в одном потоке это будет 50 часов, в 200 потоках... ты не поверишь... снова 15 минут.

[fxpc]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

Почему же, при работе, например, с сетями многопоточность рулит. То ли последовательно обрабатывать 100 подключений за 100 раз (соединение, запрос, запись ответа, рассоединение, следующий узел пока до сотого не дойдём), то ли многопоточно 100 соединений за 1 раз (запуск сразу 100 потоков, соединение, ...., рассоединение, готово!). Причём многопоточность будет выигрывать тем раз больше, чем больше количество подключений нужно обработать. А если учесть затупы связи, то это уже не преимущество даже, а необходимость.

Всё описанное не имеет никакого отношения к многопоточности и прекрасно работает в одном потоке.
Если кому-то из программистов для такого необходима многопоточность, то ему показана хирургическая коррекция расположения рук.

[_IMG]https://img.techpowerup.org/200214/8579688.jpg[/img]

100 узлов. Допустим, на соединение с узлом и скачивание тратится 15 минут. В одном потоке обработать 100 узлов займёт 25 часов. В 100 потоках 15 минут.

Или 200 узлов. В данном случае в одном потоке это будет 50 часов, в 200 потоках... ты не поверишь... снова 15 минут.

100-200 параллельных соединений без проблем обрабатываются в одном потоке. Зачем тебе отдельный поток для каждого соединения?

[Balthazar]

100 узлов. Допустим, на соединение с узлом и скачивание тратится 15 минут. В одном потоке обработать 100 узлов займёт 25 часов. В 100 потоках 15 минут.

Не допустим. Если разработчик не умеет в неблокирующие сокеты, то ему надо не писать многопоточные приложения, а увольняться.  

P.S. Скачивание файлов - это вообще бенчмарк для сети и диска, а никак не для процессора. Упереться в процессор на этой задаче нужно ещё постараться.

[Coin-1]

100 узлов. Допустим, на соединение с узлом и скачивание тратится 15 минут. В одном потоке обработать 100 узлов займёт 25 часов. В 100 потоках 15 минут.

Или 200 узлов. В данном случае в одном потоке это будет 50 часов, в 200 потоках... ты не поверишь... снова 15 минут.

Не факт. Скорость скачивания файла зависит, главным образом, от ширины пропускаемого канала.

На самом деле, создание TCP/IP-соединений и скачивание файлов можно реализовать в одном потоке путём использования неблокирующего режима, когда программа работает с сокетами через события Event. Кстати, иногда веб-серверы ограничивают скорость отдачи данных по каждому TCP/IP-соединению, тогда браузеры пытаются создать дополнительные соединения и скачивать файлы с директивой Range в HTTP-заголовках, но веб-серверы, в зависимости от настроек, обычно отвергают такие множественные соединения для обращения к одному ресурсу.

Вообще, описанная схема со множеством потоков, наверно, более актуальна для отправки ICMP-пакетов, когда необходимо быстро проверять узлы сети на доступность, пингуя большое количество IP-адресов.

[ilyapx]

Сейчас бы Boost.ASIO. использовать в 2020 году  

[DFService]

Спорить о полезности многопоточных приложений - это глупость, когда частота процессоров почти не растет, а ядер полно!
Есть полно задач, где многопоточность просто необходима.

Специализируюсь на написании многопоточных приложений на С/С++ Windows/Linux/FreeBSD
Кому нужно пишите, Telegram @dfservice, другие контакты: https://www.dfservice.com/mail/ru/

[aparatov]

Есть полно задач, где многопоточность просто необходима.

Смотря под какие задачи, есть уже много готового софта под различные требования