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

S>>>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
S>·>Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.
S> Я тебе приводил пример асинхронных примитвов синхронизации. То есть ты повторил мои же выводы
По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

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

S> ·>Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S> Прямое! Вот куча примеров https://metanit.com/sharp/tutorial/12.5.php
S> https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads
И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.

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

S>>>>Это просто оптимизация не асинхронного кода. Коего не так уж и много в том же C#.
S>>·>Нет. Это возможность запускать асинхронно синхронный код c io и синхронизированный примитивами синхронизации код.
S>> Я тебе приводил пример асинхронных примитвов синхронизации. То есть ты повторил мои же выводы
·>По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
·>Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

Еще раз IO это частный метод асинхронности. Task и выполняют огормную кучу задач вне IO.
https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
Прежде всего с ипользованием TaskCompletionSource
https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcompletionsource-1?view=net-7.0
https://habr.com/ru/articles/452094/
Есть смешение IO и TaskCompletionSource. И вторых намного больше!

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

K>·>Ну как бы не совсем. Зелёные потоки — это все потоки VM работают на одном реальном потоке и всё. А тут эти треды можно шедулить как душе угодно.
K>Раньше так не умели просто, а сейчас научились. Если бы во времена первой джавы умели скедулить как хотят, то это было бы сделано сразу.
Сразу после того, как добавили поддержку epoll/аналоги во все операционки. И потом java nio. И после того, как реализовали java.concurrent. Ну ещё method handlers. Да и без лямбд было бы грустно.
А так да, как только так сразу.

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


S>> ·>Неясно какое отношение это имеет к асинхронщине или многопоточке. Это ортогональные вещи.
S>> Прямое! Вот куча примеров https://metanit.com/sharp/tutorial/12.5.php
S>> https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads
·>И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
·>В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
·>Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.

Не обязательно.
Если ты читал есть
cts.Cancel(); if (token.IsCancellationRequested)


То есть ты должен либо опрашивать, если IsCancellationRequested == true
вызвать ThrowIfCancellationRequested

if (token.IsCancellationRequested)   
    throw new OperationCanceledException(token);

https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.cancellationtoken.throwifcancellationrequested?view=net-8.0

То есть нужно с некоторой периодичностью опрашивать token
https://learn.microsoft.com/ru-ru/dotnet/standard/threading/cancellation-in-managed-threads

Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл

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

S>·>По-моему ты что-то не понимаешь. Не нужны асинхронные примитивы синхронизации при наличии виртуальных тредов. Не нужно делать по два варианта каждой функции как в твоём примере "Wait" и "AsyncWait".
S>·>Ровно один и тот же синхронный код может выполняться как синхронно (при запуске на реальных тредах) так и асинхронно (при запуске на виртуальных тредах).

S>Еще раз IO это частный метод асинхронности. Task и выполняют огормную кучу задач вне IO.
Асинхронный IO — да, частный метод асинхронности. Но есть на свете ещё и синхронный IO. Вот такой тупой код, который писали десятки лет назад:

var data = socket.read();
var newData = processData(data);
socket.write(newData);
...

Это простой синхронный код с IO. Который легко писать, легко понимать и легко отлаживать. Виртуальные треды могут запускать его асинхронно, без изменений.

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
S>Прежде всего с ипользованием TaskCompletionSource
S>https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcompletionsource-1?view=net-7.0
S> Есть смешение IO и TaskCompletionSource. И вторых намного больше!
Так писать тоже можно. Но можно писать проще.

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

S>·>И? Это ортогональные вещи. Ровно этот же CancellationToken используется так же и в синхронном коде.
S>·>В асинхронном, как я понял, оно кидает исключение, которое ловится в результат таска. В синхронном то же исключение вываливается напрямую.
S>·>Неясно зачем для этого было создавать какой-то специальный API. Наверно, просто для универсальности.
S> Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл
Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.

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

S>> Есть смешение IO и TaskCompletionSource. И вторых намного больше!
·>Так писать тоже можно. Но можно писать проще.

Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.

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


S>> Просто его можно пробросить в кучу задач в качестве параметра и отменить эти задачи. Вот простой смысл
·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken

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

S> ·>Так писать тоже можно. Но можно писать проще.
S> Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.
Вот код:

var data = socket.read();
var newData = processData(data);
socket.write(newData);

Упрости его своим Task, коли обещал.

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

S> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?

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


S>> ·>Так писать тоже можно. Но можно писать проще.
S>> Вот именно, что Task и позволяют писать проще. IO это очень частный случай и подходит для старых проектов. Но это не киллер фича.
·>Вот код:
·>

·>var data = socket.read();
·>var newData = processData(data);
·>socket.write(newData);
·>

·>Упрости его своим Task, коли обещал.
Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

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

S>> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S>> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
·>Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?
То . что они никак не связаны. Но CancellationToken связан с задачами! Он для них и пнридуман!

S> Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

S>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

Я полагаю, что для этого будет разновидность StructuredTaskScope (тут Киллер фича JDK 21 — virtual threads) в сочетании с Executors.newVirtualThreadPerTaskExecutor (тут Киллер фича JDK 21 — virtual threads)
И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.

S>>> ·>Это всё понятно. Непонятно какое это имеет отношение к сабжу. Повторю в третий раз: Это ортогональные вещи. Прерывать можно как синхронный код, так и асинхронный. Как однопоточный код, так и многопоточный.
S>>> В том, что один из перегруженных асинхронный методов должен иметь параметр System.Threading.CancellationToken
S>·>Из один из перегруженных синхронных методов — тоже. Ты понимаешь смысл фразы "Это ортогональные вещи"?
S> То . что они никак не связаны. Но CancellationToken связан с задачами! Он для них и пнридуман!

У меня сложилось впечатление, что в Java для cancellation (по крайней мере асинхронного IO) сейчас принято использовать Future.cancel
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html
И это аналог Task в TAP модели C#, но без async/await (решили не добавлять новые конструкции языка).

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

S>> Этот код частный случай. А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?

S>>https://learn.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern#whenallorfirstexception

M>Я полагаю, что для этого будет разновидность StructuredTaskScope (тут Киллер фича JDK 21 — virtual threads) в сочетании с Executors.newVirtualThreadPerTaskExecutor (тут Киллер фича JDK 21 — virtual threads)
M>И по аналогичной схеме можно сделать всё, что написано по твоей ссылке.
Ну и в итоге зачем зоопарк городить?

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

S>·>Упрости его своим Task, коли обещал.
S> Этот код частный случай.
Соврал ты, короче. Проще не получается.
Любой кусок кода — это частный случай.

S>А вот теперь мне надо запустить несколько чтений и прервать все есть один из них вызвал исключение?
Это никакого отношения к сабжу не имеет. Но в качестве ликбеза:

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, Вы писали:

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

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


M>У меня сложилось впечатление, что в Java для cancellation (по крайней мере асинхронного IO) сейчас принято использовать Future.cancel
M>https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html
M>И это аналог Task в TAP модели C#, но без async/await (решили не добавлять новые конструкции языка).

Фича Task что он прекрасно может работать и без async/await через события в ContinueWith
но с ними оно намного приятнее. Поэтому и в JS их тоже завезли

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

Ну задачи появились еще в .NET Framework 4.0 была выпущена 12 апреля 2010 года
И главная фича acync/await была продолжение yield для создания автомата
Понятно, что Таски это не дотнетовское изобретение. Но и отнюдь не явовское