В сентябре обещают зарелизить JEP 444

Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
А вот в ирланге preemption есть

	Скрытый текст
	вроде

ну так тоже самое что и в го
только а эрлашланге еще и на каждом атоме перешедулинг вроде как есть

Здравствуйте, reversecode, Вы писали:

r> ну так тоже самое что и в го
В го это специальные языковые конструкции типа go, chan, прибито гвоздями. virtual threads это обычная многопоточка — хочешь локи, хочешь латчи, блокирующие очереди, и т.п.

r> только а эрлашланге еще и на каждом атоме перешедулинг вроде как есть
Там вообще эти жуткие акторы, иммутабельные сообщения только. Взять и и тупо расшарить данные между тредами — фигушки.

Здравствуйте, σ, Вы писали:

σ> ·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
σ> А вот в ирланге preemption есть

	Скрытый текст
	вроде

Там с перформансом не всё радужно. И акторы... сомнительное удовольствие.
Виртуальные треды это про асинхронное выполнение простого синхронного кода, скорее.

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

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

Здравствуйте, reversecode, Вы писали:

r> не совсем понятно в техническом плане что там они такого сделали
Возможность подменять стеки на уровне рантайма. И собственно всё.

r> если в эршланге вытесняющий атом то в яве сделали каждую инструкцию что ли
r> ну т.е. как в обычном cpu где ОС каждый поток может прервать в любой момент
Виртуальные треды перешедулятся на реальные треды в момент всяких многопоточных действий, типа locks, yield, sleep и т.п. Если виртуальный тред будет внутри себя крутить вычислительный цикл, то он займёт реальный тред. Т.е. кооперативная многозадачность или асинк с человеческим лицом.

Когда в при исполнении кода виртуального треда происходил блокировка/етс — стек сохраняется в куче, и добавляется таск в шедулер на продолжение. Шедулер берёт очередной таск, восстанавливает стек и монтирует его на реальный тред. И так по кругу.
Сами стеки — это маленькие кусочки порядка сотни байт.

r> времени разбираться нет
r> так что если будет инфа о технических подробностях, закидывайте сюда
Собственно кроме свопа стека ничего магического нет. Это не магия компилятора, не изменение в языке, никаких новых ключевых слов или конструкций не появилось, а просто библиотечное расширение существующих API в JDK.

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

r> рано или поздно народ конечно разберет все на кусочки в статьях и докладах
Тут небольшая статья: https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/

r> как го и его шедуллер который затянули и в котлин и в раст как минимум
r> ну и в эршланге он там почти такой же только сильно наговнокоден
Нет никакого специального нового магического шедулера. Используется уже давно существующий ForkJoinPool.

Честно говоря, я сам ещё нигде это не пытался применить (вроде как уже доступно как preview), но по демкам в интернете выглядит хорошо.

R>не совсем понятно в техническом плане что там они такого сделали
R>если в эршланге вытесняющий атом то в яве сделали каждую инструкцию что ли
R>ну т.е. как в обычном cpu где ОС каждый поток может прервать в любой момент
R>времени разбираться нет
R>так что если будет инфа о технических подробностях, закидывайте сюда

В ЖЕПе написано что time sharing нет, вытеснение на блокирующихся операциях

ну тогда так как я и сказал
го тоже вытесняет на блокирующих вызовах
плюс еще и на каждых вызовах любой его функции

Здравствуйте, ·, Вы писали:

·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
Получается, так к какому-то варианту зелёных потоков которые были в первых джавах и вернулись?

Здравствуйте, Kernan, Вы писали:

K>·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
K>Получается, так к какому-то варианту зелёных потоков которые были в первых джавах и вернулись?
Ну как бы не совсем. Зелёные потоки — это все потоки VM работают на одном реальном потоке и всё. А тут эти треды можно шедулить как душе угодно. Это альтернатива await/asynс, actors, корутин и прочего.

Здравствуйте, ·, Вы писали:

·>Виртуальные треды перешедулятся на реальные треды в момент всяких многопоточных действий, типа locks, yield, sleep и т.п. Если виртуальный тред будет внутри себя крутить вычислительный цикл, то он займёт реальный тред. Т.е. кооперативная многозадачность или асинк с человеческим лицом.

·>Когда в при исполнении кода виртуального треда происходил блокировка/етс — стек сохраняется в куче, и добавляется таск в шедулер на продолжение. Шедулер берёт очередной таск, восстанавливает стек и монтирует его на реальный тред. И так по кругу.
·>Сами стеки — это маленькие кусочки порядка сотни байт.

Можно короче объяснить : если взять Win 16 и добавить работу на нескольких ядрах, то оно и получится. Только там в качестве потоков были задачи.

Здравствуйте, Kernan, Вы писали:

K>·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
K>Получается, так к какому-то варианту зелёных потоков которые были в первых джавах и вернулись?

Не вернулись, а добавили. Это опциональная конструкция для использования которой нужно использовать специальное API (для запуска виртуального потока). Обычные потоки никуда не делись.

Как там эти потоки в жаве работали в те древние времена, мне самому интересно. В линуксе потоки в принципе были своеобразные тогда, не такие, как сейчас. На солярисе вроде жава умела в полноценные зелёные потоки, которые выполнялись на куче ОС потоков. На винде хз.

·>Там вообще эти жуткие акторы, иммутабельные сообщения только. Взять и и тупо расшарить данные между тредами — фигушки.

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

Но для начального освоения требуется чуть больше шевелить мозгами, что мешает популярности.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>·>Когда в при исполнении кода виртуального треда происходил блокировка/етс — стек сохраняется в куче, и добавляется таск в шедулер на продолжение. Шедулер берёт очередной таск, восстанавливает стек и монтирует его на реальный тред. И так по кругу.
PD>·>Сами стеки — это маленькие кусочки порядка сотни байт.
PD>Можно короче объяснить : если взять Win 16 и добавить работу на нескольких ядрах, то оно и получится. Только там в качестве потоков были задачи.
Честно говоря я не знаю как win16 работало и уж тем более внутренности. Но полагаю задачи надо хитрым образом описывать. Тут же обыкновенный плоский код плюс кучу видов многопоточных паттернов взаимодействия только из коробки — locks, cond-vars, latches, exchange, futures, concurrent collections, етс.

Здравствуйте, SkyDance, Вы писали:

SD>·>Там вообще эти жуткие акторы, иммутабельные сообщения только. Взять и и тупо расшарить данные между тредами — фигушки.
SD>Именно это и позволяет практически неограниченную масштабируемость, а также многие другие ценные штуки вроде прямого запрета девелоперу выстрелить себе в ногу.
SD>Но для начального освоения требуется чуть больше шевелить мозгами, что мешает популярности.
В этом и прикол, что сабж позволяет то же, но без высокого порога вхождения.

зеленые потоки которые вернули в яву и размазал на форк джин пуле
https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/
как оказывается форк джоин пул явовский уже умеет ворк стилинг
а именно вокруг него и прыгали разрабы токио пытаясь его слизать с го
а потом и в котлине итд скомуниздили

в чем то, это тоже самое что сделали в расте, только в расте это стеклесс корутины

жаль не удалось нагуглить(https://github.com/openjdk/) сами изменения которые внесены в jvm и sdk
но поверхностно теперь понятно

·>В этом и прикол, что сабж позволяет то же, но без высокого порога вхождения.

Порог вхождения в Java на самом деле намного выше.
Спасает только sunk cost, то, что люди уже потратили годы (начиная со школы, или самостоятельного изучения). В Британии мне понравилось, что некоторые профессоры в их министерство образования пытаются продвинуть чуть более разнообразные программы. Чтобы у детей было понимание других вариантов, кроме императивщины и прочих лого-бейсиков. От которых, понятное дело, путь в Джаву проще, чем в функциональные языки.

Здравствуйте, reversecode, Вы писали:

r> а именно вокруг него и прыгали разрабы токио пытаясь его слизать с го
Что за токио?

r> жаль не удалось нагуглить(https://github.com/openjdk/) сами изменения которые внесены в jvm и sdk
https://github.com/openjdk/jdk/pull/13203

https://tokio.rs/blog/2019-10-scheduler

Здравствуйте, ·, Вы писали:

·>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

В яву завезли goroutines?

Здравствуйте, σ, Вы писали:

σ>А вот в ирланге preemption есть

А в гошечке не только preemption есть, но еще и компиляция в машинный код.

Pzz>А в гошечке не только preemption есть, но еще и компиляция в машинный код.

В Erlang'е тоже. Причем сначала было именно как "компиляция" (HiPE), потом сделали нормальный JIT/AOT (и грохнули неудобный HiPE).

Здравствуйте, SkyDance, Вы писали:

Pzz>>А в гошечке не только preemption есть, но еще и компиляция в машинный код.

SD>В Erlang'е тоже. Причем сначала было именно как "компиляция" (HiPE), потом сделали нормальный JIT/AOT (и грохнули неудобный HiPE).

Ерланг же динамически типизован. Разве в динамически типизованном языке возможна генерация эффективного кода?

Здравствуйте, Pzz, Вы писали:

σ>>А вот в ирланге preemption есть

Pzz>А в гошечке не только preemption есть, но еще и компиляция в машинный код.

В жаве тоже есть.

Pzz>Ерланг же динамически типизован. Разве в динамически типизованном языке возможна генерация эффективного кода?

Там строгая система типов. Конструкции типа 2 + "string" являются ошибочными. И вообще, динамическая типизация — свойство компиляторе, в AOT есть часть загрузчика байт-кода.

Конкретно Erlang решает эту задачу путем внедрения compiler type information в байт-код. Тут здорово помогает тот факт, что все переменные иммутабельны, и их тип может быть выведен заранее на этапе компиляции.

PS: обрати внимание на dialyzer. Он вообще все типы выводит статически.

Здравствуйте, Pzz, Вы писали:

Pzz>В яву завезли goroutines?

Нет, это невытесняющая многозадачность, реализованная на уровне JVM. Когда код вызывает любую блокирующую операцию (wait/sleep/synchronized/blocking io), управление передается в джавовый планировщик, который сохранит текущий стек и запустит на выполнение какой-нибудь другой кусок кода с сохраненным стеком.

Здравствуйте, Pzz, Вы писали:

Pzz> В яву завезли goroutines?
Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.

Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.

Здравствуйте, ·, Вы писали:

·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.

Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?

Здравствуйте, ·, Вы писали:

·>В сентябре обещают зарелизить JEP 444

·>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

Можно. Судя по тому, что джава-девелоперы до сих пор удивляются лямбдам и сидят на джава 1.8, эта фича в массы дойдет лет через 10, а к тому времени её возьмут и выбросят, как это было с зелеными потоками.

Здравствуйте, Pauel, Вы писали:

P>·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
P>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?
Тут уже отвечали.
Помимо обычных блокировок в виде локов, они ещё переработали синхронное IO, например. Т.е. тупой линейный код как в go socket.readAllBytes(); ... socket.write(response);, тред для каждого клиента и внутре случается магия всяких epoll, виртуальный тред на блокирующем io так же перешедуливается.

Здравствуйте, Pauel, Вы писали:

P>·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.

P>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?

Насколько я понимаю — никаким. Вечный цикл займёт тред навсегда. И если треды кончатся, то всё встанет колом (в отличие от настоящих потоков).

Здравствуйте, vsb, Вы писали:

P>>Каким образом джава узнает, что вон тот метод у нас работает долго и при его вызове надо бы перешедулить?
vsb>Насколько я понимаю — никаким. Вечный цикл займёт тред навсегда. И если треды кончатся, то всё встанет колом (в отличие от настоящих потоков).
Тут немного не так. Точнее совсем не так.
Если бесконечный цикл — ошибка в коде, то виртуальный тред займёт настоящий и никакому другому виртуальному треду больше не отдаст, будет жрать cpu. По сути виртуальный тред как бы выродится в настоящий. Т.е. это утечка ресурса.
Если это просто некий временный load burst и большое число виртуальных тредов начнёт чего-то усердно считать, то они начнут захапывать реальные треды из пула. И там уже от настроек пула зависит. Например, пул может пытаться неограниченно создавать новые реальные треды пока память не закончится или ОС не начнёт протестовать. По дефолту пул, вроде, ограничивается числом ядер в cpu.

Т.е. всё как настоящие потоки получается. Плохая кооперация виртуальных тредов тупо вырождает их в настоящие. Единственное, что пропадает fairness — те виртуальные треды которые захапали все настоящие, то остальным виртуальным тредам ничего не достанется, пока те не начнут отдавать захапанное.

Здравствуйте, ·, Вы писали:

·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.

В каком смысле, не состыкуются. В go есть локи, а есть каналы. Что хочешь, то и пользуй. То, что там есть специальный синтаксис для запуска потока разве чего-то меняет?

Здравствуйте, Pauel, Вы писали:

P> Можно. Судя по тому, что джава-девелоперы до сих пор удивляются лямбдам и сидят на джава 1.8,
Ну на 1.8 сидят далеко не все, обычно те, у которых очень много легаси кода. Но, как мне кажется, сабж может быть хорошим преимуществом — запускать древний синхронный тормозной код асинхронно. Т.е. взять старый код с бизнес логикой, которая ходит синхронно туда-сюда в базу, в файлы, в SOAP и т.п, и замасштабировать на тысячи тредов, без пенальти от ОС.

А я что-то не припомню фич между 1.8 и JDK 20 которые как-то могут улучшить работу и использование старого кода, обычно только упрощения для написания нового. Ну может какие-то новые алгоритмы GC... дополнительные всяческие оптимизации, да и наверное всё.

P> эта фича в массы дойдет лет через 10, а к тому времени её возьмут и выбросят, как это было с зелеными потоками.
По-моему зелёные потоки были по сути затычкой к ОС-тредам в то время, когда среди ОС реализация тредов была большим разбродом и шатанием, да и многопроцессорные системы были редкостью.
Когда большинство ОС стали более менее вменяемо уметь в треды, то их и выкинули, тупо за ненадобностью.

Сейчас же стал популярен асинхронный код, для которого и сделали сабж.

Здравствуйте, Pzz, Вы писали:

Pzz> ·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.
Pzz> В каком смысле, не состыкуются. В go есть локи, а есть каналы. Что хочешь, то и пользуй. То, что там есть специальный синтаксис для запуска потока разве чего-то меняет?
В принципе да, для go это немного другое, т.к. там аналога VM нет. Java это платформа, там крутятся много языков. Если бы сабж реализовали как спец-синтаксис в ЯП — было бы жуть.

Здравствуйте, ·, Вы писали:

·>Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

Получается автоматическая асинхроность без всякого переписывания кода. Умно, ждем в .NET такое.

A>·>Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

A>Получается автоматическая асинхроность без всякого переписывания кода. Умно, ждем в .NET такое.

Ну как не переписывать: нужно как минимум создать экземпляр VirtualThread и запихнуть туда лямбду с кодом (а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
(https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)

·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.

Погодите, а как же cancellation?
Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.

Здравствуйте, m2user, Вы писали:

m> ·>Виртуальные треды же — это обычные треды, но с кооперативной многозадачностью. Никаких изменений в ЯП нет, всё на уровне рантайма, просто теперь можно выполнять обычный код с классическими локами и тому подобными обычными механизмами синхронизации между тредами, но без накладных расходов которые связаны с реальными ОС-тредами.
m> Погодите, а как же cancellation?
Банальный interrupt() например, доступный ещё с java 1.0.
Ну или Future.cancel() или любой другой паттерн.

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

m> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken . Итого намножилось аж 12 методов. И это приходится размазывать повсюду.

Здравствуйте, m2user, Вы писали:

m> A>·>Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
m> A>Получается автоматическая асинхроность без всякого переписывания кода. Умно, ждем в .NET такое.
m> Ну как не переписывать: нужно как минимум создать экземпляр VirtualThread и запихнуть туда лямбду с кодом
Лямбды тут непричём. Вообще.
wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.

m>(а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
Шо?! Они переменные со стека не умеют захватывать только. Как собственно и в шарпе.

m> Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
m> (https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)
С тем, что код тупой, обычный, синхронный, понятный любому индусу, без всякого мусора async/await, возможно написанный ещё до создания самого c#. Гугли "function coloring".

m>> Погодите, а как же cancellation?
·>Банальный interrupt() например, доступный ещё с java 1.0.
·>Ну или Future.cancel() или любой другой паттерн.

И как это применимо к классическим локам без переписывания кода?
Если мне нужно отменить ожидание на lock, то придется его в VirtualThread обернуть?

Дополнение:
Согласно документации
Thread.interrupt не действует на обычную synchronized секцию, и не на любой Lock

Further, the ability to interrupt the ongoing acquisition of a lock may not be available in a given Lock class

Кроме того, согласно https://openjdk.org/jeps/444

There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:

When it executes code inside a synchronized block or method, or
When it executes a native method or a foreign function.

В JEP предлагают заменить synchronized block на ReentrantLock, т.е. придется править код.


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

m>> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
·>Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken . Итого намножилось аж 12 методов. И это приходится размазывать повсюду.

Так и VirtualThread тоже самое.
Вместо await Task будет VirtualThread.join

Как в примере, из статьи на которую ты ссылался

@SneakyThrows
static void concurrentMorningRoutine() {
  var bathTime = bathTime();
  var boilingWater = boilingWater();
  bathTime.join();
  boilingWater.join();
}

·>Лямбды тут непричём. Вообще.
·>wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.

Можно и без лямбд, но Runnable/Callable при создании VirtualThread передать придется.

m>>(а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
·>Шо?! Они переменные со стека не умеют захватывать только. Как собственно и в шарпе.

Разницу C# и Java применительно к захвату переменных лямбдами обсуждали тут: Класс для возврата значения из лямбды
Мне для получения результата Callable, обернутого в VirtualThread, придется к таким же ухищрениям прибегать, как в той теме?

m>> Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
m>> (https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)
·>С тем, что код тупой, обычный, синхронный, понятный любому индусу, без всякого мусора async/await, возможно написанный ещё до создания самого c#. Гугли "function coloring".

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

static Thread bathTime() {
  return virtualThread(
    "Bath time",
    () -> {
      log("I'm going to take a bath");
      sleep(Duration.ofMillis(500L));
      log("I'm done with the bath");
    });
}

И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?

M>Мне для получения результата Callable, обернутого в VirtualThread, придется к таким же ухищрениям прибегать, как в той теме?

M>И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?

Посмотрел https://openjdk.org/jeps/444
Там есть поясняющий пример:

void handle(Request request, Response response) {
    var url1 = ...
    var url2 = ...
 
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        var future1 = executor.submit(() -> fetchURL(url1));
        var future2 = executor.submit(() -> fetchURL(url2));
        response.send(future1.get() + future2.get());
    } catch (ExecutionException | InterruptedException e) {
        response.fail(e);
    }
}
 
String fetchURL(URL url) throws IOException {
    try (var in = url.openStream()) {
        return new String(in.readAllBytes(), StandardCharsets.UTF_8);
    }
}

По-видимому Executors.newVirtualThreadPerTaskExecutor — предполагаемое решение для обоих случаев.
Но разворачивать ExecutionException до IOException придется вручную

Здравствуйте, m2user, Вы писали:

M>·>Лямбды тут непричём. Вообще.
M>·>wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.
M>Можно и без лямбд, но Runnable/Callable при создании VirtualThread передать придется.
Не понял. Для реального треда тоже. И что?

m>>>(а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
M>·>Шо?! Они переменные со стека не умеют захватывать только. Как собственно и в шарпе.
M>Разницу C# и Java применительно к захвату переменных лямбдами обсуждали тут: Класс для возврата значения из лямбды
Просто шарп компилятор создаёт класс, неявно делая переменную которая выглядит как на стеке полем класса. Грабля как из javascript.
Лично мне подход java нравится больше, т.к. никакой магии не делается, всё явно, никаких сюрпризов.

M>Мне для получения результата Callable, обернутого в VirtualThread, придется к таким же ухищрениям прибегать, как в той теме?
У callable есть возвращаемое значение.
Ты, видимо, что-то не так понял. Для запуска треда хоть реального, хоть виртуального, тебе надо как-то передать код который будет там работать. Это везде так, и в C# и даже в C. И к сабжу это никакого отношения не имеет.
Для более удобных способов обмена данными между тредами есть свой инструментарий, очень много разного.

И никакого публичного класса VirtualThread нет. С сабжем у тебя в коде будет всё тот же класс Thread из java 1.0. Меняется только способ создания экземпляра класса.

m>>> Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
m>>> (https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)
M>·>С тем, что код тупой, обычный, синхронный, понятный любому индусу, без всякого мусора async/await, возможно написанный ещё до создания самого c#. Гугли "function coloring".
M>Ты утверждал, что код остается "плоским", однако из примеров в статье видно, что вложенность увеличивается
Увеличивается по сравнению с чем?

M>И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?
Ничего не меняется. Как работало с обычными Thread, так и будет.

Иными словами, весь существующий threading API у тебя сохраняется как есть. А сабж даёт тебе возможность запустить миллион тредов.

Здравствуйте, m2user, Вы писали:

M>Так и VirtualThread тоже самое.
M>Вместо await Task будет VirtualThread.join

M>Как в примере, из статьи на которую ты ссылался
M>

M>@SneakyThrows
M>static void concurrentMorningRoutine() {
M>  var bathTime = bathTime();
M>  var boilingWater = boilingWater();
M>  bathTime.join();
M>  boilingWater.join();
M>}
M>

Лично мне больше нравится вариант джавы, а то все эти async/await как будто не лезут в голову молодому поколению девелоперов. Хотя, в целом, трудно сказать, насколько легко будет писать код для новой версии джавы. Наверняка там тоже будет много хитрых вещей "вызывайте вот это, если на двадцать уровней по стеку вверх не было вон того"

Здравствуйте, ·, Вы писали:

·>wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.

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

Здравствуйте, m2user, Вы писали:

M>>Мне для получения результата Callable, обернутого в VirtualThread, придется к таким же ухищрениям прибегать, как в той теме?
M>>И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?
M>По-видимому Executors.newVirtualThreadPerTaskExecutor — предполагаемое решение для обоих случаев.
Это такой пример. Тут из треда который выполняет handle (которых уже может быть овердофига), запускается ещё два новых треда и ожидается их завершение.
Покажи аналогичный код лучше.

Это не предполагаемое решение (решение вообще чего??), а демонстрация того, что вместо того как принято сейчас — глобальный пул тредов, который запускается при старте приложения осторожно используется, теперь пул можно просто внутри любого метода на секундочку создать, забабахать туда кучку тредов и тут же выкинуть.

Заметь, там есть readAllBytes в двух тредах. Т.е. это вот так выглядит асинхронный IO с epoll теперь.

M>Но разворачивать ExecutionException до IOException придется вручную
Зачем? И почему _придётся_?

Здравствуйте, Pauel, Вы писали:

P>·>wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.
P>Старинный код скорее всего сделан последовательным и он будет скорее всего нереэнтерабельным, да с тред-локал.
Дык тред-локал он и для виртуального треда локал!

P> Соответсвенно уже на этом можно нарыть кучу граблей, если сделать такое многопоточным.
Я имею в виду, что у тебя есть некий скажем http-сервер, в хендлерах которых у тебя последовательный код, который ходит в базу, в файлы, етс, и отдаёт результат — и всё последовательно. Сейчас такое можно намасштабировать на 200 одновременных соединений, по треду на каждое, начнёт разбухать память и т.п. С сабжем треды будут виртуальные и их можно дофига.

Здравствуйте, m2user, Вы писали:

M>·>Банальный interrupt() например, доступный ещё с java 1.0.
M>·>Ну или Future.cancel() или любой другой паттерн.
M>И как это применимо к классическим локам без переписывания кода?
M>Если мне нужно отменить ожидание на lock, то придется его в VirtualThread обернуть?
Непонятно что ты хочешь. Виртуальные треды не дают какой-то новый дополнительный контроль над локами. Они просто позволяют запускать больше тредов, чем ОС может себе позволить.
Если у тебя в коде не было возможности прервать какой-то лок, то она не появится магически. Просто пока миллион тредов висят на этом локе, ещё миллион тредов могут продолжать работать.

M>В JEP предлагают заменить synchronized block на ReentrantLock, т.е. придется править код.
Да, ложка дёгтя есть. Вроде обещают исправить: "In a future release we may be able to remove pinning inside synchronized".

m>>> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
M>·>Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken . Итого намножилось аж 12 методов. И это приходится размазывать повсюду.

M>Так и VirtualThread тоже самое.
M>Вместо await Task будет VirtualThread.join
Не совсем. Этот await не нужно протаскивать везде.
Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.

Здравствуйте, ·, Вы писали:

·>Дык тред-локал он и для виртуального треда локал!

Особенность виртуальных тредов и важный бенефит — ничтожный футпринт по памяти. С тред локалами эта особенность исчезает.

·>Я имею в виду, что у тебя есть некий скажем http-сервер, в хендлерах которых у тебя последовательный код, который ходит в базу, в файлы, етс, и отдаёт результат — и всё последовательно. Сейчас такое можно намасштабировать на 200 одновременных соединений, по треду на каждое, начнёт разбухать память и т.п. С сабжем треды будут виртуальные и их можно дофига.

Если разрабы позаботились и жестко изолировались от фремворка http-сервера, то будет бенефит и можно масштабировать.
Но реально такой изоляцией судя по коду мало кто занимается.
На собесах любят поговорить про Clean Architecture, fremwork as a detail и тд, но вот в реальном мире таких применений ничтожное количество.
И это видно в тестах — на самом низком уровне люди пишут моки т.к. ктото где то в тредлокалах прокидывает чорт знает что.

Здравствуйте, Pauel, Вы писали:

P>·>Дык тред-локал он и для виртуального треда локал!
P>Особенность виртуальных тредов и важный бенефит — ничтожный футпринт по памяти. С тред локалами эта особенность исчезает.
А... ну да. Если тред-локал используется для протаскивания UserId, то ок.
А если кто-то решил, что тред-локал это хорошее место куда можно забабахать потокобезопасный кеш, а про ConcurrentHashMap ему не рассказали, "ведь тредов всё равно не может быть больше сотни", то да, не получится отмасштабировать as-is, придётся переписывать.

P>·>Я имею в виду, что у тебя есть некий скажем http-сервер, в хендлерах которых у тебя последовательный код, который ходит в базу, в файлы, етс, и отдаёт результат — и всё последовательно. Сейчас такое можно намасштабировать на 200 одновременных соединений, по треду на каждое, начнёт разбухать память и т.п. С сабжем треды будут виртуальные и их можно дофига.
P>Если разрабы позаботились и жестко изолировались от фремворка http-сервера, то будет бенефит и можно масштабировать.
P>Но реально такой изоляцией судя по коду мало кто занимается.
Servlet API это подразумевает.

P>На собесах любят поговорить про Clean Architecture, fremwork as a detail и тд, но вот в реальном мире таких применений ничтожное количество.
В ентерпрайзе, который сидит на 1.8 — дофига. (

P>И это видно в тестах — на самом низком уровне люди пишут моки т.к. ктото где то в тредлокалах прокидывает чорт знает что.
Ну по сути это глобальный Map<ThreadId, Object>. Вот что будет Object — уже от ситуации зависит...

·>Не понял. Для реального треда тоже. И что?

·>И никакого публичного класса VirtualThread нет. С сабжем у тебя в коде будет всё тот же класс Thread из java 1.0. Меняется только способ создания экземпляра класса.

M>>·>С тем, что код тупой, обычный, синхронный, понятный любому индусу, без всякого мусора async/await, возможно написанный ещё до создания самого c#. Гугли "function coloring".
M>>Ты утверждал, что код остается "плоским", однако из примеров в статье видно, что вложенность увеличивается
·>Увеличивается по сравнению с чем?

M>>И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?
·>Ничего не меняется. Как работало с обычными Thread, так и будет.

·>Иными словами, весь существующий threading API у тебя сохраняется как есть. А сабж даёт тебе возможность запустить миллион тредов.

Да, я в курсе, что тип Thread остался старый.

Тут нужно определиться, к какому legacy коду ты собираешься применить virtualThread.
Если речь идет о http сервере (в этом твоем сообщении Киллер фича JDK 21 — virtual threads), в котором уже использются тяжеловесные треды (по одному на запрос), то конечно перевести его на легковесные вируальные треды (и получить экономию ресурсов) легко.
По сути нужно только заменить Lock на их interruptible версии.

Если же речь о коде, где нужно распараллелить операции, которые до этого выполнялись последовательно, то такой код понадобится раздробить на Runnable/Callable составляющие (функции или лямбды), попутно переписывая работу с переменными на стеке, возвратом результата, обработкой исключений.

Я утверждаю, что для такого кода:
1) по объему работы это не проще перевода на await/async
2) await/async позволил бы писать более "плоский" код (меньше вложенных блоков кода)

Executors.newVirtualThreadPerTaskExecutor, которыей я упомянул в соседнем сообщении, частично облегчает ситуацию — с возвратом результата Callable и пробросом исключения (в виде ExecutionException)

M>>По-видимому Executors.newVirtualThreadPerTaskExecutor — предполагаемое решение для обоих случаев.
·>Это такой пример. Тут из треда который выполняет handle (которых уже может быть овердофига), запускается ещё два новых треда и ожидается их завершение.
·>Покажи аналогичный код лучше.

Async/await, как оно сделано в C#. Но конечно оно потребует и async версии readAllBytes.

M>>Но разворачивать ExecutionException до IOException придется вручную
·>Зачем? И почему _придётся_?

Для реализации нетривиальной логики обработки IOException — либо обрабатывать внутри fetchURL, либо разворачивать ExecutionException до IOException.

m>>>> Вот в C# например я не могу использовать обычную lock секцию с async/await и вместо этого вынужден делать крит. секцию на основе SemaphoreSlim, где есть асинхронный wait и Cancellation.
M>>·>Именно. Вот об этом гне и говорю. Есть Wait, и ещё нужен AsyncWait и ещё с CancellationToken . Итого намножилось аж 12 методов. И это приходится размазывать повсюду.

M>>Так и VirtualThread тоже самое.
M>>Вместо await Task будет VirtualThread.join
·>Не совсем. Этот await не нужно протаскивать везде.
·>Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.

Это неполноценный асинхронный код, т.к. нет cancellation.
Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring

Здравствуйте, m2user, Вы писали:

M>Если же речь о коде, где нужно распараллелить операции, которые до этого выполнялись последовательно, то такой код понадобится раздробить на Runnable/Callable составляющие (функции или лямбды), попутно переписывая работу с переменными на стеке, возвратом результата, обработкой исключений.

M>Я утверждаю, что для такого кода:
M>1) по объему работы это не проще перевода на await/async
На порядок проще.
Вот у тебя код:

var details1 = someBigDao.complexBusinessLogicWhichDoesALotOfSQLQueriesSynchronously();//работает 20 секунд
var details2 = someService.itGoesToNetworkAndDownloadsDataUsingSomeCrazySoapFramework();//работает 30 секунд
return compbine(details1, details2);//общее время 50 секунд

В шарпе если ты такой код завернёшь в async, то толку никакого, т.к. первый же sql.execute() полезет синхронно в сокет и заблокирует твой async пока тот ждёт ответа от sql-сервера. Чтобы эти два метода запустить и чтобы они работали одновременно — тебе нужно запустить два честных треда.
Либо переписать всё на async-методы, чтобы они протаскивали Task по всему коду:
Т.е. если где-то внутре есть код типа

Result complexBusinessLogicWhichDoesALotOfSQLQueriesSynchronously()
{
  var r1 = sql.query(aaa);
  var r2 = sql.query(bbb);
  var r3 = sql.query(ccc);
  var r4 = anotherStuffWhichDoesSql(r2);
  return new Result(....);
}

то каждый sql.query тебе нужно придётся оборачивать в async и так по всей глубине стека.

С виртуальными тредами — ты просто пускаешь эти два метода и они работают параллельно:

var details1 = executor.submit(() -> someDao.complexBusinessLogicWhichDoesALotOfSQLQueriesSynchronously());
var details2 = executor.submit(() -> someService.downloadDataUsingSomeCrazySoapFramework()));
return combine(details1.join(), details2.join());//общее время 30 секунд

Всё. Ничего внутри someDao или someService менять не нужно.

M>2) await/async позволил бы писать более "плоский" код (меньше вложенных блоков кода)
Не позволил бы. Или показывай что ты имеешь в виду.

M>Executors.newVirtualThreadPerTaskExecutor, которыей я упомянул в соседнем сообщении, частично облегчает ситуацию — с возвратом результата Callable и пробросом исключения (в виде ExecutionException)
Проброс исключений, callable и прочее не имеет никакого отношения к сабжу.

Здравствуйте, ·, Вы писали:


·>Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.

Интересно а как сосуществуют виртуальные потоки с тасками?
https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?redirectedfrom=MSDN&amp;view=net-7.0

Здравствуйте, m2user, Вы писали:

M>Executors.newVirtualThreadPerTaskExecutor, которыей я упомянул в соседнем сообщении, частично облегчает ситуацию — с возвратом результата Callable и пробросом исключения (в виде ExecutionException)
Наверное ты вот это хочешь. Но это уже не новости, в JDK 19 уже доступно:

Response handle() throws ExecutionException, InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        Future<String>  user  = scope.fork(() -> findUser());
        Future<Integer> order = scope.fork(() -> fetchOrder());

        scope.join();           // Join both forks
        scope.throwIfFailed();  // ... and propagate errors

        // Here, both forks have succeeded, so compose their results
        return new Response(user.resultNow(), order.resultNow());
    }
}

Опять же, это ортогонально к VT, работает на любых тредах, и на реальных, и на виртуальных.

Здравствуйте, Serginio1, Вы писали:

S>·>Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.
S>Интересно а как сосуществуют виртуальные потоки с тасками?
Я вопрос не понял. Тасков нет никаких с виртуальными потоками.
Отдельный AsyncLocal никакой не нужен, т.к. работает ровно тот же ThreadLocal.

Помимо морально устаревшенго ThreadLocal пилят ещё ScopedValue

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

S>>·>Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.

S>>Интересно а как сосуществуют виртуальные потоки с тасками?
·>Я вопрос не понял. Тасков нет никаких с виртуальными потоками.
Ну например в .Net уже и не найти синхронных методов.
Я так понимаю, что перед вызовом readAllBytes сохраняется стек, вызывается асинхронный метод по завершении которого возвращается стек и продолжение происходит с после readAllBytes.

То есть компилятор должен знать что есть асинхронный readAllBytes?

Можно ли смешивать асинхронный код и виртуальные потоки?

Здравствуйте, m2user, Вы писали:

M>>>По-видимому Executors.newVirtualThreadPerTaskExecutor — предполагаемое решение для обоих случаев.
M>·>Это такой пример. Тут из треда который выполняет handle (которых уже может быть овердофига), запускается ещё два новых треда и ожидается их завершение.
M>·>Покажи аналогичный код лучше.
M>Async/await, как оно сделано в C#. Но конечно оно потребует и async версии readAllBytes.
Угу. И так по всему коду — всё потребует async версию.

M>>>Но разворачивать ExecutionException до IOException придется вручную
M>·>Зачем? И почему _придётся_?
M>Для реализации нетривиальной логики обработки IOException — либо обрабатывать внутри fetchURL, либо разворачивать ExecutionException до IOException.
Я не очень понимаю. Приведи пример. Для чего тебе требуется вынимать IOException? Если у тебя что-то работает в другом потоке, неважно виртуальном или реальном, то тебе нужно как-то передать исключение между потоками. Исключения обычно логгируют, да и всё.

Здравствуйте, m2user, Вы писали:

M>·>Не совсем. Этот await не нужно протаскивать везде.
M>·>Т.е. у тебя есть какой-то обычный бизнес-код с синхронным readAllBytes — и у него никакого Task/async нет. И join нужен только собственно чтобы дождаться результата от всех тредов.
M>Это неполноценный асинхронный код, т.к. нет cancellation.
А зачем он везде в общем случае? Специальная конструкция как в CancellationToken не требуется.

M>Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring
Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
Т.е. какой-то универсальный cancellation не нужен.

Здравствуйте, Serginio1, Вы писали:

S>·>Я вопрос не понял. Тасков нет никаких с виртуальными потоками.
S> Ну например в .Net уже и не найти синхронных методов.
Точнее количество методов удвоено — синхронный вариант и асинхронный.

S> Я так понимаю, что перед вызовом readAllBytes сохраняется стек, вызывается асинхронный метод по завершении которого возвращается стек и продолжение происходит с после readAllBytes.
S> То есть компилятор должен знать что есть асинхронный readAllBytes?
Нет никакого специального асинхронного readAllBytes. Как я понял отсюда, он отдаёт задание на чтение байтов реальному глобальному jvm-треду "Read-Poller" и блокируется в ожидании результата. Блокировка позволяет отсоединить виртуальный тред (сохраняя стек) и положить его в очередь.
И компилятор тут непричём. Это просто детали реализации socket api.

"<unnamed>" #15 virtual
  java.base/java.lang.Continuation.yield(Continuation.java:402)
...
  java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:60)
...
  java.base/java.net.Socket$SocketInputStream.read(Socket.java:988)
...
  java.base/java.io.InputStream.readAllBytes(InputStream.java:346)

"Read-Poller" #16
  java.base@17-internal/sun.nio.ch.KQueue.poll(Native Method)
...
  java.base@17-internal/java.lang.Thread.run(Thread.java:1522)
  java.base@17-internal/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:161)

S> Можно ли смешивать асинхронный код и виртуальные потоки?
Никакого особого магического асинхронного кода со всякими генерёнными конечными автоматами в java нет. Поэтому что ты хочешь смешивать неясно.

Здравствуйте, ·, Вы писали:


·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.

Где то в начале стека определилось, что не нужны дальнейшие вычисления. Как мне их все прервать по всему стеку?

Здравствуйте, ·, Вы писали:


S>> Я так понимаю, что перед вызовом readAllBytes сохраняется стек, вызывается асинхронный метод по завершении которого возвращается стек и продолжение происходит с после readAllBytes.
S>> То есть компилятор должен знать что есть асинхронный readAllBytes?
·>Нет никакого специального асинхронного readAllBytes. Как я понял отсюда, он отдаёт задание на чтение байтов реальному глобальному jvm-треду "Read-Poller" и блокируется в ожидании результата. Блокировка позволяет отсоединить виртуальный тред (сохраняя стек) и положить его в очередь.
·>И компилятор тут непричём. Это просто детали реализации socket api.

То есть это касается только сокетов?

Здравствуйте, Serginio1, Вы писали:

S>·>И компилятор тут непричём. Это просто детали реализации socket api.
S> То есть это касается только сокетов?
Весь io.

Здравствуйте, Serginio1, Вы писали:

S>·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
S> Где то в начале стека определилось, что не нужны дальнейшие вычисления. Как мне их все прервать по всему стеку?
Можно пример?
Если ты в том же SemaphoreSlim вызывается async wait без cancellation token — как прервать?
Вообще cancellation ортогонален асинхронщине. Посмотри, там есть и синхронный wait с cancellation token.
Врочем, можно использовать thread.interrupt().

Здравствуйте, ·, Вы писали:

S>>·>И компилятор тут непричём. Это просто детали реализации socket api.
S>> То есть это касается только сокетов?
·>Весь io.
Ну это понятно. Просто Tаsk это не только IO.
https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern

Здравствуйте, ·, Вы писали:


S>>·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
S>> Где то в начале стека определилось, что не нужны дальнейшие вычисления. Как мне их все прервать по всему стеку?
·>Можно пример?
·>Если ты в том же SemaphoreSlim вызывается async wait без cancellation token — как прервать?
·>Вообще cancellation ортогонален асинхронщине. Посмотри, там есть и синхронный wait с cancellation token.
·>Врочем, можно использовать thread.interrupt().
Это конечно да!
Суть в том, что может быть цепочка асинхронных вызовов вплоть до рекурсии.
То есть внутри метода вызывает асинхронный метод и так далее

Здравствуйте, Serginio1, Вы писали:

S>·>Если ты в том же SemaphoreSlim вызывается async wait без cancellation token — как прервать?
S>·>Вообще cancellation ортогонален асинхронщине. Посмотри, там есть и синхронный wait с cancellation token.
S>·>Врочем, можно использовать thread.interrupt().
S> Это конечно да!
S> Суть в том, что может быть цепочка асинхронных вызовов вплоть до рекурсии.
S>То есть внутри метода вызывает асинхронный метод и так далее
Т.е. у тебя должен быть специально написанный код, который предусматривает прерывание в предусмотренных местах. Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.

Здравствуйте, Serginio1, Вы писали:

S>·>Весь io.
S>Ну это понятно. Просто Tаsk это не только IO.
Именно IO доставляет проблемы потокам.

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
Это аналог Future или StructuredTaskScope как в примере выше. Тоже ортогонально тредам.

Здравствуйте, ·, Вы писали:

S>> Суть в том, что может быть цепочка асинхронных вызовов вплоть до рекурсии.
S>>То есть внутри метода вызывает асинхронный метод и так далее
·>Т.е. у тебя должен быть специально написанный код, который предусматривает прерывание в предусмотренных местах. Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
Конечно! Обычно методы и принимают параметр System.Threading.CancellationToken
https://learn.microsoft.com/ru-ru/dotnet/api/system.io.filestream.readasync?view=net-7.0

Здравствуйте, ·, Вы писали:

S>>·>Весь io.
S>>Ну это понятно. Просто Tаsk это не только IO.
·>Именно IO доставляет проблемы потокам.

Не обязательно. Народ запускает кучу параллельных потоков для распараллеливания задач, сервера, причем используют примитивы синхронизации.
С помощью Task можно решать кучу задач с помощь небольшого количества потоков.
Например SemaphoreSlim.WaitAsync
https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.semaphoreslim.waitasync?view=net-7.0

Здравствуйте, Serginio1, Вы писали:

S>>>·>Весь io.
S>>>Ну это понятно. Просто Tаsk это не только IO.
S>·>Именно IO доставляет проблемы потокам.
S> Не обязательно. Народ запускает кучу параллельных потоков для распараллеливания задач, сервера, причем используют примитивы синхронизации.
S>С помощью Task можно решать кучу задач с помощь небольшого количества потоков.
Да ясен пень. Сабж как раз про то, что не нужно решать задачи с помощью Task, которому нужно специальные ключевые слова в язык, который требует от компилятора перекорёживать код, заставляет писать два варианта каждого метода, затрудняет понимание и отладку кода. Вместо этого можно просто иметь большое количество потоков.

Здравствуйте, ·, Вы писали:

S>>>>Ну это понятно. Просто Tаsk это не только IO.
S>>·>Именно IO доставляет проблемы потокам.
S>> Не обязательно. Народ запускает кучу параллельных потоков для распараллеливания задач, сервера, причем используют примитивы синхронизации.
S>>С помощью Task можно решать кучу задач с помощь небольшого количества потоков.
·>Да ясен пень. Сабж как раз про то, что не нужно решать задачи с помощью Task, которому нужно специальные ключевые слова в язык, который требует от компилятора перекорёживать код, заставляет писать два варианта каждого метода, затрудняет понимание и отладку кода. Вместо этого можно просто иметь большое количество потоков.
Нееее. Это частный метод с одним уровнем. Как правило таски это многоуровневые вложения.
Я не вижу особых проблем с async/await. А вот с виртуальными потоками вижу. То есть совместно с тасками их не применить.
Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.

Здравствуйте, Serginio1, Вы писали:

S>·>Да ясен пень. Сабж как раз про то, что не нужно решать задачи с помощью Task, которому нужно специальные ключевые слова в язык, который требует от компилятора перекорёживать код, заставляет писать два варианта каждого метода, затрудняет понимание и отладку кода. Вместо этого можно просто иметь большое количество потоков.
S> Нееее. Это частный метод с одним уровнем. Как правило таски это многоуровневые вложения.
Нет. async/await — это виртуальные треды для бедных.

S> Я не вижу особых проблем с async/await. А вот с виртуальными потоками вижу. То есть совместно с тасками их не применить.
Тут уже несколько примеров приводили с Future и StructuredTaskScope.

S>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.

Здравствуйте, Serginio1, Вы писали:

S> ·>Т.е. у тебя должен быть специально написанный код, который предусматривает прерывание в предусмотренных местах. Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S> Конечно! Обычно методы и принимают параметр System.Threading.CancellationToken
Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.

Здравствуйте, ·, Вы писали:

·>Ну как бы не совсем. Зелёные потоки — это все потоки VM работают на одном реальном потоке и всё. А тут эти треды можно шедулить как душе угодно.
Раньше так не умели просто, а сейчас научились. Если бы во времена первой джавы умели скедулить как хотят, то это было бы сделано сразу.

Здравствуйте, ·, Вы писали:

S>>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
·>Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.
Я тебе приводил пример асинхронных примитвов синхронизации. То есть ты повторил мои же выводы

Здравствуйте, ·, Вы писали:

S>> ·>Т.е. у тебя должен быть специально написанный код, который предусматривает прерывание в предусмотренных местах. Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S>> Конечно! Обычно методы и принимают параметр System.Threading.CancellationToken
·>Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.

Прямое! Вот куча примеров https://metanit.com/sharp/tutorial/12.5.php
https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads

Здравствуйте, Serginio1, Вы писали:

S>>>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
S>·>Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.
S> Я тебе приводил пример асинхронных примитвов синхронизации. То есть ты повторил мои же выводы
По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

Здравствуйте, Serginio1, Вы писали:

S> ·>Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S> Прямое! Вот куча примеров https://metanit.com/sharp/tutorial/12.5.php
S> https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads
И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.

Здравствуйте, ·, Вы писали:

S>>>>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
S>>·>Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.
S>> Я тебе приводил пример асинхронных примитвов синхронизации. То есть ты повторил мои же выводы
·>По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
·>Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

Еще раз IO это частный метод асинхронности. Task и выполняют огормную кучу задач вне IO.
https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
Прежде всего с ипользованием TaskCompletionSource
https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcompletionsource-1?view=net-7.0
https://habr.com/ru/articles/452094/
Есть смешение IO и TaskCompletionSource. И вторых намного больше!

Здравствуйте, Kernan, Вы писали:

K>·>Ну как бы не совсем. Зелёные потоки — это все потоки VM работают на одном реальном потоке и всё. А тут эти треды можно шедулить как душе угодно.
K>Раньше так не умели просто, а сейчас научились. Если бы во времена первой джавы умели скедулить как хотят, то это было бы сделано сразу.
Сразу после того, как добавили поддержку epoll/аналоги во все операционки. И потом java nio. И после того, как реализовали java.concurrent. Ну ещё method handlers. Да и без лямбд было бы грустно.
А так да, как только так сразу.

Здравствуйте, ·, Вы писали:


S>> ·>Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S>> Прямое! Вот куча примеров https://metanit.com/sharp/tutorial/12.5.php
S>> https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads
·>И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
·>В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
·>Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.

Не обязательно.
Если ты читал есть
cts.Cancel(); if (token.IsCancellationRequested)


То есть ты должен либо опрашивать, если IsCancellationRequested == true
вызвать ThrowIfCancellationRequested

if (token.IsCancellationRequested)   
    throw new OperationCanceledException(token);

https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.cancellationtoken.throwifcancellationrequested?view=net-8.0

То есть нужно с некоторой периодичностью опрашивать token
https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads

Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл

Здравствуйте, Serginio1, Вы писали:

S>·>По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
S>·>Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

S>Еще раз IO это частный метод асинхронности. Task и выполняют огормную кучу задач вне IO.
Асинхронный IO — да, частный метод асинхронности. Но есть на свете ещё и синхронный IO. Вот такой тупой код, который писали десятки лет назад:

var data = socket.read();
var newData = processData(data);
socket.write(newData);
...

Это простой синхронный код с IO. Который легко писать, легко понимать и легко отлаживать. Виртуальные треды могут запускать его асинхронно, без изменений.

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
S>Прежде всего с ипользованием TaskCompletionSource
S>https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcompletionsource-1?view=net-7.0
S> Есть смешение IO и TaskCompletionSource. И вторых намного больше!
Так писать тоже можно. Но можно писать проще.

Здравствуйте, Serginio1, Вы писали:

S>·>И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
S>·>В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
S>·>Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.
S> Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл
Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.

Здравствуйте, ·, Вы писали:

S>> Есть смешение IO и TaskCompletionSource. И вторых намного больше!
·>Так писать тоже можно. Но можно писать проще.

Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.

Здравствуйте, ·, Вы писали:


S>> Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл
·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken

Здравствуйте, Serginio1, Вы писали:

S> ·>Так писать тоже можно. Но можно писать проще.
S> Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.
Вот код:

var data = socket.read();
var newData = processData(data);
socket.write(newData);

Упрости его своим Task, коли обещал.

Здравствуйте, Serginio1, Вы писали:

S> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?

Здравствуйте, ·, Вы писали:


S>> ·>Так писать тоже можно. Но можно писать проще.
S>> Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.
·>Вот код:
·>

·>var data = socket.read();
·>var newData = processData(data);
·>socket.write(newData);
·>

·>Упрости его своим Task, коли обещал.
Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

Здравствуйте, ·, Вы писали:

S>> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S>> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
·>Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?
То . что они никак не связаны. Но CancellationToken связан с задачами! Он для них и пнридуман!

S> Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

Я полагаю, что для этого будет разновидность StructuredTaskScope (тут Киллер фича JDK 21 — virtual threads) в сочетании с Executors.newVirtualThreadPerTaskExecutor (тут Киллер фича JDK 21 — virtual threads)
И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.

S>>> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S>>> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
S>·>Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?
S> То . что они никак не связаны. Но CancellationToken связан с задачами! Он для них и пнридуман!

У меня сложилось впечатление, что в Java для cancellation (по крайней мере асинхронного IO) сейчас принято использовать Future.cancel
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html
И это аналог Task в TAP модели C#, но без async/await (решили не добавлять новые конструкции языка).

Здравствуйте, m2user, Вы писали:

S>> Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

S>>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

M>Я полагаю, что для этого будет разновидность StructuredTaskScope (тут Киллер фича JDK 21 — virtual threads) в сочетании с Executors.newVirtualThreadPerTaskExecutor (тут Киллер фича JDK 21 — virtual threads)
M>И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.
Ну и в итоге зачем зоопарк городить?

Здравствуйте, Serginio1, Вы писали:

S>·>Упрости его своим Task, коли обещал.
S> Этот код частный случай.
Соврал ты, короче. Проще не получается.
Любой кусок кода — это частный случай.

S>А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?
Это никакого отношения к сабжу не имеет. Но в качестве ликбеза:

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception
А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:

<T> CompletableFuture<List<T>> WhenAllOrFirstException(CompletableFuture<T>... tasks) 
{
    var all = CompletableFuture.allOf(tasks);
    Stream.of(tasks).forEach(t -> t.exceptionally(ex -> 
    {
        all.completeExceptionally(ex);
        return null;
    }));
    return all.thenApply(x -> Stream.of(tasks).map(f -> f.join()).toList());
}

Здравствуйте, Serginio1, Вы писали:

M>>И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.
S>Ну и в итоге зачем зоопарк городить?
В том, что ты не понял какие задачи решает сабж.
Перечитай топик, внимательно.

Здравствуйте, m2user, Вы писали:


M>У меня сложилось впечатление, что в Java для cancellation (по крайней мере асинхронного IO) сейчас принято использовать Future.cancel
M>https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html
M>И это аналог Task в TAP модели C#, но без async/await (решили не добавлять новые конструкции языка).

Фича Task что он прекрасно может работать и без async/await через события в ContinueWith
но с ними оно намного приятнее. Поэтому и в JS их тоже завезли

Здравствуйте, ·, Вы писали:
>>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:

Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
И главная фича acync/await была продолжение yield для создания автомата
Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

M>>>И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.
S>>Ну и в итоге зачем зоопарк городить?
·>В том, что ты не понял какие задачи решает сабж.
·>Перечитай топик, внимательно.

Читаю

Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
Зачем нужен зоопарк с виртуальными потоками?

Здравствуйте, ·, Вы писали:

S>>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception
·>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
·>

·><T> CompletableFuture<List<T>> WhenAllOrFirstException(CompletableFuture<T>... tasks) 
·>{
·>    var all = CompletableFuture.allOf(tasks);
·>    Stream.of(tasks).forEach(t -> t.exceptionally(ex -> 
·>    {
·>        all.completeExceptionally(ex);
·>        return null;
·>    }));
·>    return all.thenApply(x -> Stream.of(tasks).map(f -> f.join()).toList());
·>}
·>

И где здесь виртуальные потоки?

Здравствуйте, Serginio1, Вы писали:

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S> Зачем нужен зоопарк с виртуальными потоками?

Здравствуйте, Serginio1, Вы писали:

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>Зачем нужен зоопарк с виртуальными потоками?

А кто сказал что виртуальные потоки можно использовать только для io ?

Здравствуйте, Pauel, Вы писали:

S>> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>>Зачем нужен зоопарк с виртуальными потоками?

P>А кто сказал что виртуальные потоки можно использовать только для io ?
Автор топика. Надо читать всю ветку.
Смысл в CancellationToken, работа с задачей, а не результатом задачи использование TaskCompletionSource

Здравствуйте, Serginio1, Вы писали:

P>>А кто сказал что виртуальные потоки можно использовать только для io ?
S>Автор топика. Надо читать всю ветку

Все, что делается через Task в дотнете, можно делать через виртуальные треды. Только код будет выглядеть иначе.

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

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, Serginio1, Вы писали:

P>>>А кто сказал что виртуальные потоки можно использовать только для io ?
S>>Автор топика. Надо читать всю ветку

P>Все, что делается через Task в дотнете, можно делать через виртуальные треды. Только код будет выглядеть иначе.

P>IO в данном случае уже поддерживается рантаймом, перешедуливание будет работать само. А вот всё остальное нужно разумеется вставлять связку самостоятельно, ровно так же, как вы это делаете через ContinueWith итд.

Ну и какой смысл в ограниченном IO? Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, ·, Вы писали:
>>>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S>Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
Task (2010 год) это аналог Future (2004 год). А там в коде TaskCompletionSource (2020 год) который реализует удобную функциональность которая есть в CompletableFuture (2014 год).

S>И главная фича acync/await была продолжение yield для создания автомата
S> Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское
Возможно. Даже если и так, просто видно дотнет отстаёт на ~5 лет. Вангую, что лет через пять ты создашь топик "Киллер фича c# — виртуальные треды", хотя не уверен, что осилят.

Здравствуйте, Serginio1, Вы писали:

S>Читаю
S>

S>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
S>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>Зачем нужен зоопарк с виртуальными потоками?
Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.

Здравствуйте, Serginio1, Вы писали:

S>·>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S> И где здесь виртуальные потоки?
Я ответил в том сообщении, но ты не удосужился прочитать или даже просто отквотить: "Это никакого отношения к сабжу не имеет. Но в качестве ликбеза:"

Здравствуйте, ·, Вы писали:

S>>Здравствуйте, ·, Вы писали:
>>>>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S>>Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
·>Task (2010 год) это аналог Future (2004 год). А там в коде TaskCompletionSource (2020 год) который реализует удобную функциональность которая есть в CompletableFuture (2014 год).
TaskCompletionSource вместе с тасками

S>>И главная фича acync/await была продолжение yield для создания автомата
S>> Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское
·>Возможно. Даже если и так, просто видно дотнет отстаёт на ~5 лет. Вангую, что лет через пять ты создашь топик "Киллер фича c# — виртуальные треды", хотя не уверен, что осилят.
Смысла тасков без TaskCompletionSource нет в .Net она появилась вместе с тасками в 2010 а в Яве в 2014. Кто опаздывает?
Ну и не создам точно ибо мне async/await ну никак не напрягает. Наоборот код более понятен.
Но я рад за вас, что вы так довольны этой фичей

Здравствуйте, ·, Вы писали:

S>> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>>Зачем нужен зоопарк с виртуальными потоками?
·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга.

Здравствуйте, Serginio1, Вы писали:

S> Ну и какой смысл в ограниченном IO? Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
S> В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!
Графы тасков требуется создавать только в маленькой части кода, где требуется разворачивать и сворачивать параллельное исполнение крупных блоков (а мелочь параллелить смысла вообще нет). Это будет внутри одного метода.
Весь остальной код проще писать (и понимать, и тестировать, и отлаживать) последовательно и линейно.
task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.

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

Здравствуйте, ·, Вы писали:


·>task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.
Уже давно нет синхронной реализации. Вернее можно получить через Result или task.GetAwaiter().GetResult()
·>Я понимаю, может быть ты старательный и трудолюбивый, любишь копипасту, две строчки кода считаешь не серьёзным. Но я лентяй и раздолбай — мне бы вкинуть пару строчек кода и забыть.

Копипасту все любят. Только и интеллисенсе и ИИ в VS это не проблема

Здравствуйте, ·, Вы писали:


·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.

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

·>А зачем он везде в общем случае? Специальная конструкция как в CancellationToken не требуется.

M>>Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring
·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
·>Т.е. какой-то универсальный cancellation не нужен.

Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.).
Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.

non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Как учесть это в стороннем коде, мне не ясно.

	См. https://stackoverflow.com/a/37207163
	Here's a SUPER FUN EXAMPLE: ch.qos.logback.core.AsyncAppenderBase prior to version 1.1.4 catches and swallows InterruptedException without resetting the flag on the thread. So, if you use anything which routes to this logger (like slf4j), it will silently eat your thread interrupt status. 'Cos, I mean, who doesn't check thread interrupt status before and after every possible log operation?

Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.

При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.

P.S. nickname у сообщения почему-то поменялся на Аноним Правильный nick — m2user

S>>>·>И компилятор тут непричём. Это просто детали реализации socket api.
S>>> То есть это касается только сокетов?
S>·>Весь io.
S>Ну это понятно. Просто Tаsk это не только IO.

На всякий случай приведу полный список модифицированного:
https://openjdk.org/jeps/444

Detailed changes

The remaining subsections describe, in detail, the changes we propose across the Java Platform and its implementation:

java.lang.Thread
Thread-local variables
java.util.concurrent
Networking
java.io
Java Native Interface (JNI)
Debugging (JVM TI, JDWP, and JDI)
JDK Flight Recorder (JFR)
Java Management Extensions (JMX)

Т.е. не только IO, например Lock тоже поддерживаются (кроме synchronized block).

Здравствуйте, Serginio1, Вы писали:

S> ·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
S> Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга.
Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое.

Здравствуйте, Serginio1, Вы писали:

S> ·>task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.
S> Уже давно нет синхронной реализации. Вернее можно получить через Result или task.GetAwaiter().GetResult()
Где нет?

S> ·>Я понимаю, может быть ты старательный и трудолюбивый, любишь копипасту, две строчки кода считаешь не серьёзным. Но я лентяй и раздолбай — мне бы вкинуть пару строчек кода и забыть.
S> Копипасту все любят. Только и интеллисенсе и ИИ в VS это не проблема
Не говори за всех.

Здравствуйте, mrTwister, Вы писали:

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

Здравствуйте, mrTwister, Вы писали:

T> ·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.

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

https://riteeksrivastava.medium.com/a-complete-journey-with-goroutines-8472630c7f5c

Scheduling of Goroutines

As I have mentioned in the last paragraph, Goroutines are cooperatively scheduled. In cooperative scheduling there is no concept of scheduler time slice. In such scheduling Goroutines yield the control periodically when they are idle or logically blocked in order to run multiple Goroutines concurrently. The switch between Goroutines happen only at well defined points — when an explicit call is made to the Goruntime scheduler. And those well defined points are:

Channels send and receive operations, if those operations would block.
The Go statement, although there is no guarantee that the new Goroutine will be scheduled immediately.
Blocking syscalls like file and network operations.
After being stopped for a garbage collection cycle.

?

Здравствуйте, rudzuk, Вы писали:

...
r> ?

Все, уже нашел

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

S>> ·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
S>> Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга.
·>Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое.
Я тебе привел ограничения твоих виртуальных потоков по сравнению с нормальными тасками. Только и всего

Здравствуйте, m2user, Вы писали:

А> ·>Т.е. какой-то универсальный cancellation не нужен.
А> Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.).
А> Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
Это уже как-то сложно и наворочено получается. Скажем, работает у тебя операция чтения в массив размером в 100 мегабайт. Половину вычиталось из сокета, и тут пришел сигнал на отмену. Что с этим делать? Вкачать выкачанное обратно в интернет?
Так что разумный вариант — закрывать сокет, прерывать чтение исключением. Что interrupt в сабже и делает, если я не ошибаюсь.

А> Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.
Если не заниматься усложнизмом, то всё ок.

А> non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Согласен, что interrupt очень по-странному реализован... Но, я надесь, простительно, ибо это было сделано с первой версии...

А> Как учесть это в стороннем коде, мне не ясно.
Это как бы баги"особенности" конкретного кода. Никто не запретит "особым" образом обрабатывать CancellationToken (если вообще ты как-то умудришься его протащить внутрь сторонней либы логгирования).

А> Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.
А> При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Честно говоря, не очень понимаю юзкейсы этого. Зачем надо всё делать отменяемым?
Насколько часто такое надо делать? Потому что если это какие-то corner cases, там это можно реализовать вручную, а не протаскивать везде и всюду.

А> Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.
Не знаю насколько это необходимо, но это ортогонально virtual threads. Добавят, так добавят.

Здравствуйте, Serginio1, Вы писали:

S> ·>Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое.
S> Я тебе привел ограничения твоих виртуальных потоков по сравнению с нормальными тасками. Только и всего
Ещё раз. Виртуальные потоки — совсем про другое.

Здравствуйте, m2user, Вы писали:

M>Т.е. не только IO, например Lock тоже поддерживаются (кроме synchronized block).
Ну под IO я прежде всего подразумевал Порты завершения ввода-вывода
https://learn.microsoft.com/ru-ru/windows/win32/fileio/i-o-completion-ports