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

S>>>·>Было мало кода, был простой код. Стало много сложного кода. Что ты хотел мне этим продемострировать?
S>>>Угу был дермовый код с блокировками потоков и хранением переменных привязанных к потоку.
S>·>Что в этом плохого?
S> Ты серьезно? Проблема серверов в переключении потоков, на это тратится время.
Хорошо, но уже лучше.
Т.е. на самом деле-то не сам код дерьмо, а дерьмо в переключении потоков, на которое тратится время.

S>При использовании задач используется пул потоков, а задача представляет собой замыкание с автоматом переходов после выполнения задачи.
Вот и представь себе, что существуют такие потоки, на переключение которых не тратится время! Код перестанет быть дерьмовым с твоей точки зрения?

S>>>Стал неблокирующий потоки, при этом код внутри монитора может быть асинхронный и переменные привязанные к задаче.
S>·>Чем это лучше?
S> Ну во первых lock используется только внутри одного потока, при использовании асинхронного подхода нужно использовать SemaphoreSlim.
Ты, видимо, на какой-то другой вопрос ответил. Я спросил, чем лучше, а не где что нужно унутре использовать. Для меня как-то не очевидно, что нужда чего-то где-то делать является чем-то хорошим...

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

S>>При использовании задач используется пул потоков, а задача представляет собой замыкание с автоматом переходов после выполнения задачи.
·>Вот и представь себе, что существуют такие потоки, на переключение которых не тратится время! Код перестанет быть дерьмовым с твоей точки зрения?
Виртуальные потоки это примитивный аналог задач.

S>>>>Стал неблокирующий потоки, при этом код внутри монитора может быть асинхронный и переменные привязанные к задаче.
S>>·>Чем это лучше?
S>> Ну во первых lock используется только внутри одного потока, при использовании асинхронного подхода нужно использовать SemaphoreSlim.
·>Ты, видимо, на какой-то другой вопрос ответил. Я спросил, чем лучше, а не где что нужно унутре использовать. Для меня как-то не очевидно, что нужда чего-то где-то делать является чем-то хорошим...

Еще раз ответь себе на вопросы про Task.WhenAll, Task.WhenAny, CancellationToken
И как ты аналог TaskCompletionSource (CompletableFuture) будешь использовать в виртуальных потоках.

Так у задач есть свойство IsCompleted. Например Task.FromResult возвращает результат и задача не прерывается.

Еще раз виртуальные потоки хороши для старого кода, а вот для нового кода с async/await c Task.WhenAll, Task.WhenAny, CancellationToken, TaskCompletionSource
дает больше возможностей.

Это как претензии к Delphi насчет begin end. В студии есть подсказка и написать await не проблема за то дает больше степеней свободы.

Много примеров ты найдешь здесь
Использование асинхронного шаблона на основе задач

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

S>·>Вот и представь себе, что существуют такие потоки, на переключение которых не тратится время! Код перестанет быть дерьмовым с твоей точки зрения?
S> Виртуальные потоки это примитивный аналог задач.
В точности наоборот. Задачи — примитивный кривой костыль при отсутствии возможности использовать потоки без проблем с производительностью. Ты же это сам кодом продемонстрировал.

S>>>·>Чем это лучше?
S>>> Ну во первых lock используется только внутри одного потока, при использовании асинхронного подхода нужно использовать SemaphoreSlim.
S>·>Ты, видимо, на какой-то другой вопрос ответил. Я спросил, чем лучше, а не где что нужно унутре использовать. Для меня как-то не очевидно, что нужда чего-то где-то делать является чем-то хорошим...
S> Еще раз ответь себе на вопросы про Task.WhenAll, Task.WhenAny,
CompletableFuture.allOf и CompletableFuture.anyOf

S> CancellationToken
thread.interrupt() или CompletableFuture.cancel. При этом не надо этот твой мусор везде таскать через параметры.

S>И как ты аналог TaskCompletionSource (CompletableFuture) будешь использовать в виртуальных потоках.
Ровно так же, как и в обычных. В этом и сила.

S>Так у задач есть свойство IsCompleted.
Future.isDone

S>Например Task.FromResult возвращает результат и задача не прерывается.
CompletableFuture.completedFuture

S> Еще раз виртуальные потоки хороши для старого кода, а вот
Они хороши для любого кода. Ты же сам это продемонстировал.

S>для нового кода с async/await c Task.WhenAll, Task.WhenAny, CancellationToken, TaskCompletionSource дает больше возможностей.
Как оказалось — не даёт.

S>Это как претензии к Delphi насчет begin end. В студии есть подсказка и написать await не проблема за то дает больше степеней свободы.
Ты просто в суть вникнуть не можешь, т.к. проблемы с чтением. Вот про CompletableFuture упомянул, но, очевидно, даже доку не открывал. Иначе бы не писал этот бред.

S>Много примеров ты найдешь здесь
S>Использование асинхронного шаблона на основе задач
Зачем мне этот цирк... Мне работу работать надо, а не через обручи прыгать.

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

Вот смотрю я на асинхронное программирование в Яве

Асинхронные задачи FutureTask. Callable и Future

import java.util.concurrent.*;
 
class Program{
 
    public static void main(String[] args) {
          
        System.out.println("Main thread started...");
 
        int number = 5;  // исходное число для вычисления факториала
 
        // определяем задачу, которая вычисляет факториал
        Callable<Integer> task = () -> {
 
            int n = number;     // копируем число, чтобы не изменять его
            int result = 1;
            while(n > 0) result *= n--;
            return result;  // возвращаем результат задачи
        };
 
        // определяем задачу, которая будет выполнена в будущем
        var futureTask = new FutureTask<Integer>(task);
        // создаем и запускаем поток
        var t = new Thread(futureTask); // futureTask - это объект Runnable
        t.start();
 
        // здесь могут быть какие-либо другие операции метода main
        // которые должны выполняться одновременно с futureTask
        System.out.println("Main thread works...");
 
        try{
            // ожидаем выполнения задачи
            Integer factorial = futureTask.get();
            System.out.printf("factorial of %d is %d\n", number, factorial);
        }
        catch(Exception ex){ 
            System.out.println(ex.getMessage()); 
        }
 
        System.out.println("Main thread finished...");
    }
}

Или

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(task);
 
        // передаем в thenAccept обратный вызов
        future.thenAccept(result -> System.out.printf("factorial of %d is %d\n", number, result));
 
        // future.thenAccept - не блокирует основной поток 
        // и одновременно мы можем выполнять в основном потоке некоторую работу 
        System.out.println("Main thread works...");
  
        Thread.sleep(2000);
 
        System.out.println("Main thread finished...");

На C# будет типа такого

Task<int> task= Task.Run(()=>
 {
 
            int n = number;     // копируем число, чтобы не изменять его
            int result = 1;
            while(n > 0) result *= n--;
            return result;  // возвращаем результат задачи
        };

 // здесь могут быть какие-либо другие операции метода main
 // которые должны выполняться одновременно с futureTask

  try{
var res = await task; // или в синхронном варианте  int res = task.Result;
 }
        catch(Exception ex){ 
            Console.WriteLine(ex.ToString()); 
        }

)


В JavaScript, под влиянием TypeScript пришли к тому, что await значительно лучше чем создание цепочек обратных вызовов

CompletableFuture и промисы. Обработка результата асинхронных задач