Сообщение Re[3]: Киллер фича JDK 21 - virtual threads от 02.06.2023 12:49
Изменено 03.06.2023 8:47 vdimas
Re[3]: Киллер фича JDK 21 - virtual threads
Здравствуйте, ·, Вы писали:
·>Ну потому что в 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."
Разумеется, statefull-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.
Re[3]: Киллер фича JDK 21 - virtual threads
Здравствуйте, ·, Вы писали:
·>Ну потому что в 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-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.
·>Ну потому что в 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-корутины могут вытесняться по прерываниям, т.к. технически они мало чем отличаются от потоков уровня ОС, отличаются только владельцем-шедуллером.
Разве что при вытеснении по прерываниям теряется легковесность переключения, т.к. вызовы проходят через ядро, т.е. получается профанация.