Здравствуйте, vdimas, Вы писали:
V>Разумеется, statefull-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
V>Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.
Вот вопрос, а чем тебе автомат (async/await продолжение yield) с пулом потоков не угодил?
Вроде все проблемы озвученные тобой там отсутствуют, не надо сохранять состояние потока, состояние сохраняется в объекте владеющим автоматом.
Причем через TaskCompletionSource и CancellationToken можно управлять выполнением группы тасков или создавая свои
https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
Здравствуйте, vdimas, Вы писали:
v> ·>Ну потому что в API получилось так, что VirtualThread это потомок Thread и там где используется второе, можно подсунуть первое.
v> По-идее, в любой VM сущность Thread заведомо должна быть "виртуальной", как это сразу декларировалось для .Net, например, что не гарантируется привязка .Net-потока к потоку ОС.
До jdk21 там тоже ничего не гарантировалось афаир. А с сабжем — явно определили два вида тредов — платформные (или ядерные) и виртуальные. Чтобы можно было выбирать в зависимости от потребностей. И, что очень важно, сохранили обратную совместимость.
v> И даже если дело в наследовании, ничего не мешало назвать общепринятым словом Fiber или LightweightThread.
Тут главное consistency с платформой jvm, а не с win32 или boost, я их не считаю законодателем моды.
v> Если бы дело было в начале нулевых, я бы к идентификаторам не придирался, но на сейчас сленг в этой области уже более-менее устаканился. ))
Так ведь это немного не те фибры, которые в других местах. Т.е. полного соответсвия ничему существующему нет, поэтому вполне разумно придумать новое название.
v> ·>С практической т.з. что работает для тредов, так же работает и для виртуальных тредов.
v> Было бы лучше, чтобы все потоки стали легковесными, без ввода новой сущности.
Если бы это был новый ЯП с нуля, то, может и можно, но тогда получится Go.
Да и иметь явно платформенные потоки тоже иногда нужно, например, чтобы быть поближе к железу, для Low Latency случаев.
v> Иначе в каждой блокирующей операции придётся делать лишнюю проверку относительно вида потока.
Это забота JDK, а не прикладных программистов.
v> Разумеется, statefull-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
v> Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.
Именно, это будут обычные платформенные потоки, бесполезно. А виртуальные потоки вытеснять можно на safepoints которые уже есть для gc.
Здравствуйте, ·, Вы писали:
·>В сентябре обещают зарелизить JEP 444
·>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
·>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.
Кто-то тестировал производительность? Много сетевых запросов с virtual threads по сравнению обычным асинхронным кодом
