Подскажите, я тут прочитала про project loom, правильно ли я

понимаю, что он решит проблему нагрузки(по типу С10к) в синхронном виде, просто виртуальные потоки почему-то сравниваются с котлиновскими корутинами, но разве это не разные вещи? Корутины никак не помогают с блокирующими операциями, а только позволяют красиво писать асинхронный код(не считая IO dispatcher’а, но там же в принципе новый тред создается, так что проблема нагрузки точно не решается), или я не права?

Про какие именно блокирующие операции? В корутинах все сделано в расчете на suspend методы, при которых будет запланирована следующая корутина. В виртуальных потоках по идее любая блокирующая может приводить к планирования другой блокирующей операции, если они их все так реализуют.Но идея похожа, поэтому и сравнивают

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

Ну тут просто вопрос терминологии, они же позволяют легковесные операции, считай потоки. Да, конечно это отлично от loom, но у нас и нет его ещё. А принцип похож

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

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

Хм, я думала, что лум - это стекфул корутины как бы, как в го, например.

Все то же самое

Разница между корутинами и лумом - первые генерируют байт-код свёртки и развертки стека, а для вторых он есть в jvm

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

Нет, если поток заблокирован, то все, заблокирован

Ну вот же. Не заблокирует реальный поток. Результат около 400к. for (var i = 0; i < 1_000_000; i++) { Thread.startVirtualThread(() -> { c.incrementAndGet(); try { Thread.sleep(1_000); } catch (InterruptedException e) { e.printStackTrace(); } }); }

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

в этом примере, как я понимаю, Thread.sleep(1000) - это не настоящий слип, это что-то вроде SchedulerExecuter.schedule(this, 1000, MILLISECONDS)

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

Ну понятно, что они исполняются на реальных потоках, но нам от этого никакой разницы, для нас это обычный синхронный код, виртуальный поток заблокирются, его вытеснят, пока он не проснется и все, у них же даже в key takeways написано: Blocking a virtual thread is cheap — be synchronous!

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

А как может метод не быть готовым к работе с гринтредами, jvm контроллирует все взаимодействие между ос и приложением, просто везде будут виртуальные потоки.

Да, насколько я видел, они заменяют имплементации сетевые, с файловой системой, тот же thread.sleep. поэтому в идеальной ситуации мы получим как в го

Потому что это не блокирующий вызов в виртуальном треде

мне кажется ты тут написал неправильные вещи

Там в луме для виртуальных потоков это по сути аналог корутиновского delay()

это звучит как правда

Это что то из разряда фантастики

нет, это реальность

это ложь

Правда, даже Елизаров так говорил

пруфы

Завтра, я телефона и хочу спать

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