> Это весьма поверхностное суждение из области "если бы да кабы"...
В некоторых случаях это так, а в других совершенно иначе.
Случаи, безусловно, бывают разные, но, согласитесь, стоимость стандартных потоков, например, в JVM, значительно выше горутин. Там даже при ста потоках при вобщем-то небольшой вычислительной работе основная часть времени ЦП тратится на переключение между потоками. Плюс сами потоки жрут прилично памяти.
>P.S. Кстати, модель Go-рутин использует нативные потоки, и программа Go, даже вовсе не использующая параллелизм, тоже активно использует нативные потоки.
Ну это ясно, вообще, абсолютно любая программа их использует (самое меньшее - 1 стандартный поток, в котором она выполняется). Только вот в Go зачастую одна параллельная задача не равна одному системному потоку (их число явно ограничивается переменной GOMAXPROCS, которая по дефолту равна числу ядер, так что программа на го не может заюзать больше потоков, даже если там 1к горуцтин будет).
> А на rabbitmq nосмотреть не хотите?
А как он может помочь в данном случае? Если честно, не особо с ним знаком.
> На каждого клиента заводится очередь, из которой он черпает сообщения. Вариантов масса.
Ну да, собственно, такие варианты примерно и приходят на ум.
Но я думал, например, сделать что-то вроде такого: на клиенте хранятся id всех новых сообщений, которые он не читал и при запросе страницы новых сообщений он (клиент) отдает этот список и получает по этим ID сообщения. Ну а, когда он прочитывает какое-то из них, оно удаляется из локальной очереди. Или это плохая идея? Просто при этом не нужно на сервере для каждого клиента заводить очередь.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
