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

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

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

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

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

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

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

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

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