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

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

M>>>И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.
S>>Ну и в итоге зачем зоопарк городить?
·>В том, что ты не понял какие задачи решает сабж.
·>Перечитай топик, внимательно.

Читаю

Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
Зачем нужен зоопарк с виртуальными потоками?

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

S>>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception
·>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
·>

·><T> CompletableFuture<List<T>> WhenAllOrFirstException(CompletableFuture<T>... tasks) 
·>{
·>    var all = CompletableFuture.allOf(tasks);
·>    Stream.of(tasks).forEach(t -> t.exceptionally(ex -> 
·>    {
·>        all.completeExceptionally(ex);
·>        return null;
·>    }));
·>    return all.thenApply(x -> Stream.of(tasks).map(f -> f.join()).toList());
·>}
·>

И где здесь виртуальные потоки?

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

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S> Зачем нужен зоопарк с виртуальными потоками?

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

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>Зачем нужен зоопарк с виртуальными потоками?

А кто сказал что виртуальные потоки можно использовать только для io ?

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

S>> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>>Зачем нужен зоопарк с виртуальными потоками?

P>А кто сказал что виртуальные потоки можно использовать только для io ?
Автор топика. Надо читать всю ветку.
Смысл в CancellationToken, работа с задачей, а не результатом задачи использование TaskCompletionSource

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

P>>А кто сказал что виртуальные потоки можно использовать только для io ?
S>Автор топика. Надо читать всю ветку

Все, что делается через Task в дотнете, можно делать через виртуальные треды. Только код будет выглядеть иначе.

IO в данном случае уже поддерживается рантаймом, перешедуливание будет работать само. А вот всё остальное нужно разумеется вставлять связку самостоятельно, ровно так же, как вы это делаете через ContinueWith итд.

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

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

P>>>А кто сказал что виртуальные потоки можно использовать только для io ?
S>>Автор топика. Надо читать всю ветку

P>Все, что делается через Task в дотнете, можно делать через виртуальные треды. Только код будет выглядеть иначе.

P>IO в данном случае уже поддерживается рантаймом, перешедуливание будет работать само. А вот всё остальное нужно разумеется вставлять связку самостоятельно, ровно так же, как вы это делаете через ContinueWith итд.

Ну и какой смысл в ограниченном IO? Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!

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

S>Здравствуйте, ·, Вы писали:
>>>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S>Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
Task (2010 год) это аналог Future (2004 год). А там в коде TaskCompletionSource (2020 год) который реализует удобную функциональность которая есть в CompletableFuture (2014 год).

S>И главная фича acync/await была продолжение yield для создания автомата
S> Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское
Возможно. Даже если и так, просто видно дотнет отстаёт на ~5 лет. Вангую, что лет через пять ты создашь топик "Киллер фича c# — виртуальные треды", хотя не уверен, что осилят.

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

S>Читаю
S>

S>Можно писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
S>Кооперативная многозадачность. Виртуальные треды запускаются на пуле из ОС-тредов и на блокирующих операциях перешедулятся, стеки подменяются.

S> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>Зачем нужен зоопарк с виртуальными потоками?
Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.

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

S>·>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S> И где здесь виртуальные потоки?
Я ответил в том сообщении, но ты не удосужился прочитать или даже просто отквотить: "Это никакого отношения к сабжу не имеет. Но в качестве ликбеза:"

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

S>>Здравствуйте, ·, Вы писали:
>>>>А думаешь откуда это появилось в дотнете? Они же слизали CompletableFuture, которое было доступно ещё лет ~10 назад, хреново как-то слизали, код — жуть. Вот более вменяемый аналог:
S>>Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
·>Task (2010 год) это аналог Future (2004 год). А там в коде TaskCompletionSource (2020 год) который реализует удобную функциональность которая есть в CompletableFuture (2014 год).
TaskCompletionSource вместе с тасками

S>>И главная фича acync/await была продолжение yield для создания автомата
S>> Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское
·>Возможно. Даже если и так, просто видно дотнет отстаёт на ~5 лет. Вангую, что лет через пять ты создашь топик "Киллер фича c# — виртуальные треды", хотя не уверен, что осилят.
Смысла тасков без TaskCompletionSource нет в .Net она появилась вместе с тасками в 2010 а в Яве в 2014. Кто опаздывает?
Ну и не создам точно ибо мне async/await ну никак не напрягает. Наоборот код более понятен.
Но я рад за вас, что вы так довольны этой фичей

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

S>> Зачем если уже есть Task c ContinueWith и async/await которые решает больший круг задач чем IO.
S>>Зачем нужен зоопарк с виртуальными потоками?
·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга.

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

S> Ну и какой смысл в ограниченном IO? Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
S> В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!
Графы тасков требуется создавать только в маленькой части кода, где требуется разворачивать и сворачивать параллельное исполнение крупных блоков (а мелочь параллелить смысла вообще нет). Это будет внутри одного метода.
Весь остальной код проще писать (и понимать, и тестировать, и отлаживать) последовательно и линейно.
task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.

Я понимаю, может быть ты старательный и трудолюбивый, любишь копипасту, две строчки кода считаешь не серьёзным. Но я лентяй и раздолбай — мне бы вкинуть пару строчек кода и забыть.

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


·>task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.
Уже давно нет синхронной реализации. Вернее можно получить через Result или task.GetAwaiter().GetResult()
·>Я понимаю, может быть ты старательный и трудолюбивый, любишь копипасту, две строчки кода считаешь не серьёзным. Но я лентяй и раздолбай — мне бы вкинуть пару строчек кода и забыть.

Копипасту все любят. Только и интеллисенсе и ИИ в VS это не проблема

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


·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.

Откуда ты это взял? В go вытесняющая многозадачность, переключение горутины происходит даже если она крутит пустой цикл.

·>А зачем он везде в общем случае? Специальная конструкция как в CancellationToken не требуется.

M>>Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring
·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
·>Т.е. какой-то универсальный cancellation не нужен.

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

non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Как учесть это в стороннем коде, мне не ясно.

	См. https://stackoverflow.com/a/37207163
	Here's a SUPER FUN EXAMPLE: ch.qos.logback.core.AsyncAppenderBase prior to version 1.1.4 catches and swallows InterruptedException without resetting the flag on the thread. So, if you use anything which routes to this logger (like slf4j), it will silently eat your thread interrupt status. 'Cos, I mean, who doesn't check thread interrupt status before and after every possible log operation?

Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.

При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.

P.S. nickname у сообщения почему-то поменялся на Аноним Правильный nick — m2user

S>>>·>И компилятор тут непричём. Это просто детали реализации socket api.
S>>> То есть это касается только сокетов?
S>·>Весь io.
S>Ну это понятно. Просто Tаsk это не только IO.

На всякий случай приведу полный список модифицированного:
https://openjdk.org/jeps/444

Detailed changes

The remaining subsections describe, in detail, the changes we propose across the Java Platform and its implementation:

java.lang.Thread
Thread-local variables
java.util.concurrent
Networking
java.io
Java Native Interface (JNI)
Debugging (JVM TI, JDWP, and JDI)
JDK Flight Recorder (JFR)
Java Management Extensions (JMX)

Т.е. не только IO, например Lock тоже поддерживаются (кроме synchronized block).

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

S> ·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код.
S> Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга.
Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое.

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

S> ·>task/async же требует засорения всего кода. Прогонять это всё через много слоёв стека. Требовать дублирования для каждого метода его синхронной и асинхронной реализации.
S> Уже давно нет синхронной реализации. Вернее можно получить через Result или task.GetAwaiter().GetResult()
Где нет?

S> ·>Я понимаю, может быть ты старательный и трудолюбивый, любишь копипасту, две строчки кода считаешь не серьёзным. Но я лентяй и раздолбай — мне бы вкинуть пару строчек кода и забыть.
S> Копипасту все любят. Только и интеллисенсе и ИИ в VS это не проблема
Не говори за всех.

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

T> Откуда ты это взял? В go вытесняющая многозадачность, переключение горутины происходит даже если она крутит пустой цикл.
Не знал. Изначально там не было. Потом добавили оказывается.