AS
поток дает удобство абстракции, например работа с клиентом в веб сервере, уже потом это стало не модно и не эффективно
бери из пула, кто же запрещает
Size: a a a
2020 July 20
AS
вводи очередь запросов, твои воркеры будут эту очередь выбирать по мере того как будут освобождаться
RR
бери из пула, кто же запрещает
так никто не запрещает, просто автору вопроса порекомендовал один из путей, он не плохой если клиентов не много
МС
поток дает удобство абстракции, например работа с клиентом в веб сервере, уже потом это стало не модно и не эффективно
А в чём преимущество? Работа же проводится с данными, а не с потоком. Имеется ввиду, что можно запускать бесконечно долгие вычисления? ))
МС
Если так, то проще программировать на go.
RR
А в чём преимущество? Работа же проводится с данными, а не с потоком. Имеется ввиду, что можно запускать бесконечно долгие вычисления? ))
Что то же мотивировало первые веб серверы делать многопоточные?
МС
Не додумались до лучшей архитектуры. )
AS
Что то же мотивировало первые веб серверы делать многопоточные?
они быстро эволюционировали, как только получили первые случаи Out Of Service при исчерпании ресурсов
МС
Изначально в приложении 1 поток.
RR
они быстро эволюционировали, как только получили первые случаи Out Of Service при исчерпании ресурсов
это уже второй вопрос, однако ж удобство в этом было
МС
И потом есть такая задача C10k. А сейчас есть и задача C100k. Почитайте. )
AS
У ос при старте потоков очень много, если о настольных пк говорить, у винды пару тысяч потоков при старте. Почему вредно создавать больше , чем кол-во потоков в процессоре *2 , если их изначально много?
а много ли из них работают в этом момент, а не блокированы на ожидании какого-либа события?
RR
У ос при старте потоков очень много, если о настольных пк говорить, у винды пару тысяч потоков при старте. Почему вредно создавать больше , чем кол-во потоков в процессоре *2 , если их изначально много?
не путайте потоки и процессы
А
а много ли из них работают в этом момент, а не блокированы на ожидании какого-либа события?
а ну да, там же еще демонов много
AS
а ну да, там же еще демонов много
демон - это специальный вид процесса, который не предполагает взаимодействия с пользователем, если брать терминологию unix
МС
А вот тут можно на цифорки посмотреть, какие технологии лучше работают с highload.
https://www.techempower.com/benchmarks/
https://www.techempower.com/benchmarks/
RR
демон - это специальный вид процесса, который не предполагает взаимодействия с пользователем, если брать терминологию unix
🤨
RR
а тут boost asio уже советовали?
МС
Он же старьё.