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

·>И никакого публичного класса 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)