Асинхронная обработка tcp запросов

Нет, не укладывается, протри глаза: «без собственной значимой нагрузки проца (как у автора)».

И дело не в длительности, дело именно в нагрузке. Если обработка долгая только из-за ожидания ответа по сети минуту - это лёгкий запрос.

а треды работают ВСЕГДА.

Да, это универсальное (и простое для программиста) средство, которое пожертвовало эффективностью ради этого всего. Хочешь написать не применяя мозг и побыстрее - вот тебе треды. Хочешь заботиться об эффективности своего продукта - выбирай инструменты в зависимости от задачи. Треды - либо для числодробилок, либо для ожидания блокирующих операций с файлами. Для остального - ручное управление асинхронностью через event loop.

мощьность континиума больше 2 imho

в части как быть

Для остального - ручное управление асинхронностью через event loop.

за такое только блевики ставить.

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

вопрос - у тебя есть средства гарантировать что некий код выполняется и будет(после изменений и доработок) выполняться быстрей 10 мс? что это за код такой вообще, где есть такие гарантии. какое нить открытие файла будет длиться дольше. лазание по базам - заведомо дольше.

то есть ты должен еще и потребовать от внешних либ, чтобы любая функция работала не более 10 мс?

это соверщшенно тупиковая идея, годная только для мелких проектов, и простого baremetal.

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

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

при использовании event loop очередь клиентов будет ждать, пока идёт обработка запроса текущего клиента. если обработка долгая, то у клиентов задержка получения ответа

Что за бред? Одно из основных назначений event loop - это обработать максимальное число событий за квант времени потока. Ибо переключение контекста одна из самых дорогих операций.

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

Т.е. потоки процесса в этом случае делятся на:

1. Потоки обработки сетевых соединений и т.п.
2. Потоки обработки event loop
3. Потоки обработки вычислительно сложных задач.

З.Ы.: Как альтернатива even loop: Модель Акторов.

З.З.Ы.: Реализация своего event loop или свою модель Акторов - хорошая задача для саморазвития.

По факту нет никакой разницы на одном ядре запускать один поток или несколько.

Переключение контекста офигенно долгая операция.

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

я самолично спасал одних клоунов, что совершенно как ты делали гуй

Пожалуйста, занимаетесь UI - и продолжайте им заниматься (я даже готов предположить что у это вас неплохо получается), но перестаньте навязывать свои подходы людям которые всю сознательную жизнь бекендом занимается и собаку на этом съели. Никто в своём уме в любом high-load не будет отправлять тысячи тредов на самотёк.

Что касается плюсов и сишки, то там такой сущности нет по определению

Да щас. Куча либ ещё в 90-х было «user-space threads», например GNU Pth.

У меня ещё в 2004 году был одноядерный компьютер

А потоков было много. Это m:1 треды.

Ну, а дальше асинхронщина или зеленые потоки, без вариантов.

А на ядрах с M:N ядерными потоками продолжается открытие соединений (solaris, windows nt)

Никто в своём уме в любом high-load не будет отправлять тысячи тредов на самотёк.

об этом и речи не было, уважаемый. пожалуйста занимайтесь своей коробкой с проводами и не мешайте людям беседовать.

Справедливости ради, тот же tkInter скрывает от программиста на питоне свою асинхронную отрисовку, а в wxPython программист сам должен управлять потоками и общением их друг-с-другом. Но мне wxPython всё равно больше нравится - как-то больше контроля.

пожалуйста занимайтесь своей коробкой с проводами

Их сильно больше одной, но неважно. Не вы ли тут давеча всех убеждали что любую обработку нужно отправлять в свой тред? Цитирую: «а треды работают ВСЕГДА. хоть для сложных, хоть для простых запросов». Так вот, от того что ваши треды «работают всегда» цель в виде «все запросы обработаны» не становится сильно ближе, тогда как если мы их обрабатываем по N (по числу доступных ядер и других ресурсов) мы закончим за половину времени на запрос в среднем. С кучей дополнительных плюшек не доступных если мы всё отдаём на откуп системному планировщику.

Не вы ли тут давеча всех убеждали что любую обработку нужно отправлять в свой тред?

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

а если воркеров - N - то это получается N ивентлупов, работающих параллельно.

Да, солярис жалко. Что-то они сильно замахнулись на масштабируемость, а на простых обыденных задачах получилось медленнее, чем в линуксе. По ряду причин проиграли, и далеко не только из-за этого. Больше, наверное, сама компания Сан потянула за собой на дно.

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

Значит, ты тоже помнишь о солярисе!

Никто в своём уме в любом high-load не будет отправлять тысячи тредов на самотёк.

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

boost::thread_group натравленный на boost::asio::io_context, пишется на раз (см. маны и примеры), смысла в неиспользовании библиотек не вижу, чесгря.