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

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

S>>·>Выполнение в отдельном потоке означает параллельное выполнение. Это не отвечает на вопрос _зачем_ метод обязан быть асинхронным.
S>> Задача может выполняться как в отдельном потоке LongRunning, так и пуле потоков. А там можно настроить, что бы пул потока состоял из одного потока.
S>>Кроме того операции ввода вывода используют один поток использую один поток для контроля выполнения через контроллер.
·>ЗАЧЕМ?? Ты путаешь средство и цель.

S>>·>Речь о коде на языке программирования идёт, а не об операционной системе.
S>> Мы говорим об асинхронных методах, которые используют операции ввода вывода. Ты же спрашиваешь зачем использовать асинхронный код.
·>Зачем о них говорить? Почему в коде нельзя использовать синхронные операции ввода-вывода?

Мы по кругу одно и тоже обсуждаем. Я уже тебе писал про почему лучше использовать асинхронные методы.
S>>·>_Зачем_ он отвечает за параллельность?
S>> Затем, что Task работает как с потоками так и пулом потоков со своим планировщиком. Так же компилятор создает класс энумератор со state machine с вызовом MoveNext после выполнения await
·>Это средство, а не цель. Мне, как программисту, не надо создавать энумераторы. Мне, как программисту, надо выполнить миллион операций ввода-вывода.

Ты и не создаешь. За тебя это делает компилятор.

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

Угу смотрю я на твои StructuredTaskScope и поражаюсь явистам.

S>>·>Нет, за параллельность отвечают потоки. Создаёшь много потоков — они выполяются параллельно. То что тебе _приходится_ использовать асинхронность — это недостаток платформенных тредов. Ты их не можешь запускать миллионами, поэтому _приходится_ переписывать "старый" код. Иначе всё просто падает нахрен.
S>> Task это задача. Она отвязана от потоков. Еще раз внимательно читаем про операции ввода вывода, TaskCompletionSource
S>> Что там внутри происходит зависит от планировщика, пула потоков, опций для Task.
·>Угу. Но зачем? Почему нельзя просто писать обычный код с обычными синхронными операциями?

А потому, что кроме асинхронного выполнения есть и параллельное использование задач. Или без ожидания их выполнения.

Опять же зачем в Java StructuredTaskScope

Задачи через WhenAll, WhenAny, ContinueWith, CancellationToken намного проще использовать нежели StructuredTaskScope.

CancellationToken например нужен после выполнения WhenAny, что бы остановить невыполненные задачи.

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

S>>·>Ты задал вопрос: "как отличать Task как асинхронное и параллельное использование?". Я попросил уточнить: "с какой целью отличать?". Так зачем их отличать?
S>>Вот у тебя есть метод

S>>

S>>File.WriteAllBytesAsync("file1");
S>>

·>Зачем мне такой метод? Что плохого с File.WriteAllBytes("file1")?

S>>Не дожидаясь результата записи
·>Не надо так делать. Если тебе не важны результаты, то нафиг вообще его вызывать?

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


S>>·>Ещё раз. Это WhenAny говно в java уже есть очень давно. Но говном быть не перестаёт, т.к. усложняет код.
S>>Угу WhenAny позволяет получить результат первого выполненого и отменить выполнение еще невыполненных.
S>>Или обработать результат первого выполненного.
S>> В чем говно непонятно.
S>>Обработка асинхронных задач по мере их выполнения (C#)
·>Код сложнее. Сам же несколько сообщений назад согласился.

Сложнее по сравнению с чем? Как ты с виртуальными потоками будешь делать WhenAny?
Мне нужна первая выполненная задача!

S>> Еще раз несложно с помощью ИИ написать создание асинхронных методов если в них есть методы с имеющие методы с суффиксом Async
·>Можно. Но зачем, если есть возможно не писать такое гно вообще?

Для тебя говно, для меня нормальный универсальный код.

S>>·>Потому что не могут. Синхронный код в c# не масштабируется.
S>> Еще раз несложно через Roslyn преобразовать код.
·>Сложно. Потребуются виртуальные потоки.

Ты не пользовался анализаторами и преобразователями кода. Сейчас с ИИ несложно набросать такой преобразователь.
Виртуальные потоки хороши, но только для старого кода.

Если мы пишем новый код с 12 года, то виртуальные потоки говно ибо не универсальны.

Кстати я могу Task создать через Task.Run или TaskCompletionSource. Как для виртуальных потоков создавать такие асинхронные методы

Виртуальные потоки Java 21 — чувак, где мой lock?

S> А потому, что кроме асинхронного выполнения есть и параллельное использование задач. Или без ожидания их выполнения.

Нет никакого "параллельного выполнения задач", и задач тоже нет. Если у тебя есть виртуальные потоки, ты просто пишешь синхронный код, добавляя параллельность только там, где это требуется. Все эти Task'и — не более чем протекшая абстракция, из-за отсутствия возможности отделить IO-bound от CPU-bound, и уметь вытеснять оба типа задач.

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

S>·>Зачем о них говорить? Почему в коде нельзя использовать синхронные операции ввода-вывода?
S> Мы по кругу одно и тоже обсуждаем. Я уже тебе писал про почему лучше использовать асинхронные методы.
Потому что у тебя порочный круг.

S>>> Затем, что Task работает как с потоками так и пулом потоков со своим планировщиком. Так же компилятор создает класс энумератор со state machine с вызовом MoveNext после выполнения await
S>·>Это средство, а не цель. Мне, как программисту, не надо создавать энумераторы. Мне, как программисту, надо выполнить миллион операций ввода-вывода.
S> Ты и не создаешь. За тебя это делает компилятор.
Мне приходится расставлять async/await. Компилятор это делать не умеет.

S>>>Вот именно, что апи зависит от задач. Task универсален и легко читаем.
S>·>Нифига он не легко читаем. Примеры асинхронных очередей и т.п. ты мне тут показывал.
S> Угу смотрю я на твои StructuredTaskScope и поражаюсь явистам.
Так с WhenAny код будет ещё сложнее.

S>>> Task это задача. Она отвязана от потоков. Еще раз внимательно читаем про операции ввода вывода, TaskCompletionSource
S>>> Что там внутри происходит зависит от планировщика, пула потоков, опций для Task.
S>·>Угу. Но зачем? Почему нельзя просто писать обычный код с обычными синхронными операциями?
S> А потому, что кроме асинхронного выполнения есть и параллельное использование задач. Или без ожидания их выполнения.
Так зачем это асинхронное выполнение нужно? Для параллельного вычисления есть треды.

S>Опять же зачем в Java StructuredTaskScope
Чтобы завернуть типичные шаблоны параллелизации в минимальный простой код.

S>Задачи через WhenAll, WhenAny, ContinueWith, CancellationToken намного проще использовать нежели StructuredTaskScope.
Это ложь.

S>CancellationToken например нужен после выполнения WhenAny, что бы остановить невыполненные задачи.
С тредами CancellationToken не нужен вообще. А StructuredTaskScope сам заботится об остановке задач.

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

S>>>Не дожидаясь результата записи
S>·>Не надо так делать. Если тебе не важны результаты, то нафиг вообще его вызывать?
S> То есть например при записи логов мне не нужно знать записался он или нет.
S>Результат в записи лог мне не важен. Важно выполнение кода. Если в лог не записалось, то разбираться будем потом.
По идее это должна решать система логгирования. Если мы хотим не терять сообщения, то надо блокировать. Т.е. в самом коде должно быть

logger.info("message");

А потом уже можно настроить по ходу — блокируемся ли, или начинаем дропать сообщения, или при переполнении очереди — начать слать куда-нибудь в другое место. Притом в зависимости от logger level.

Но если тебе хочется запустить параллельно кусок кода, то ты просто запускаешь и... собственно всё:

Thread.ofVirtual().start(() -> File.WriteAllBytes("file1"));

И не нужно дублировать каждый метод. Загляни в доку File — и посмотри, что там методов в два раза больше, чем могло бы быть!

S>>>Обработка асинхронных задач по мере их выполнения (C#)
S>·>Код сложнее. Сам же несколько сообщений назад согласился.
S> Сложнее по сравнению с чем? Как ты с виртуальными потоками будешь делать WhenAny?
S>Мне нужна первая выполненная задача!
Я уже показывал код с anySuccessfulOrThrow — ровно три строчки. Заметь, код, который ответственнен за параллелизацию находится строго внутри StructuredTaskScope. Весь другой код, и выше и ниже — обычный синхронный. Не надо по всему стеку протаскивать async/await и CancellableToken.

S>>>·>Потому что не могут. Синхронный код в c# не масштабируется.
S>>> Еще раз несложно через Roslyn преобразовать код.
S>·>Сложно. Потребуются виртуальные потоки.
S> Ты не пользовался анализаторами и преобразователями кода. Сейчас с ИИ несложно набросать такой преобразователь.
S>Виртуальные потоки хороши, но только для старого кода.


S>Если мы пишем новый код с 12 года, то виртуальные потоки говно ибо не универсальны.
S>Кстати я могу Task создать через Task.Run или TaskCompletionSource. Как для виртуальных потоков создавать такие асинхронные методы
Никак. Зачем их создавать? Просто запускаешь поток, и всё.

S>Виртуальные потоки Java 21 — чувак, где мой lock?
Ты об этом уже писал, и я тебе уже про это отвечал. Хинт: Java 25.