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

·>Ну потому что в API получилось так, что VirtualThread это потомок Thread и там где используется второе, можно подсунуть первое.

По-идее, в любой VM сущность Thread заведомо должна быть "виртуальной", как это сразу декларировалось для .Net, например, что не гарантируется привязка .Net-потока к потоку ОС.
И даже если дело в наследовании, ничего не мешало назвать общепринятым словом Fiber или LightweightThread.

GreenThread не пойдёт, т.к. этот термин используется обычно там, где легковесные потоки создаются и управляются некоей подсистемой автоматически, типа как в Erlang.
Обычных потоков там нет, а которые есть — зеленые.
Если бы дело было в начале нулевых, я бы к идентификаторам не придирался, но на сейчас сленг в этой области уже более-менее устаканился. ))


·>С практической т.з. что работает для тредов, так же работает и для виртуальных тредов.

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


·>Более того, есть техническая возможность вытеснять виртуальные треды и возможно это даже появится в будущем.
·>"You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually."

Разумеется, statefull-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.

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

·>Ну потому что в API получилось так, что VirtualThread это потомок Thread и там где используется второе, можно подсунуть первое.

По-идее, в любой VM сущность Thread заведомо должна быть "виртуальной", как это сразу декларировалось для .Net, например, что не гарантируется привязка .Net-потока к потоку ОС.
И даже если дело в наследовании, ничего не мешало назвать общепринятым словом Fiber или LightweightThread.

GreenThread не пойдёт, т.к. этот термин используется обычно там, где легковесные потоки создаются и управляются некоей подсистемой автоматически, типа как в Erlang.
Обычных потоков там нет, а которые есть — зеленые.
Если бы дело было в начале нулевых, я бы к идентификаторам не придирался, но на сейчас сленг в этой области уже более-менее устаканился. ))


·>С практической т.з. что работает для тредов, так же работает и для виртуальных тредов.

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


·>Более того, есть техническая возможность вытеснять виртуальные треды и возможно это даже появится в будущем.
·>"You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually."

Разумеется, stackful-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.