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

S>·>Зачем тебе асинхронная очередь при наличии виртуальных тредов? Используй обычный BlockingQueue.
S>·>Впрочем, пишется очень похожим образом, если очень надо, используя CompletableFuture.
S> Я не пишу на Java мне интересно как для TaskCompletionSource прикурутить виртуальные потоки.
Ещё раз. Это ортогональные понятия. Для виртуальных потоков task не нужен. Точнее можно создать обычный thread pool и создавать в нём таски, как обычно. Просто этому пулу передаётся фабрика виртуальных потоков, вместо платформенных по дефолту. Но это не является необходимостью, т.к. task-и не нужны для виртуальных потоков, можно использовать обычные примитивы синхронизации и любой блокирующий IO, т.к. наличие миллионов ждущих потоков не будет проблемой.
Более того, потоки — часть рантайма, а не часть ЯП. Т.е. можно не только писать свои удобные библиотеки всякой хитровывернутой многопоточки по своему вкусу, но это всё так же доступно в любом jvm-based языке — scala/kotlin какой-нибудь.

S>

S>static ProductPayload fetchProduct(long id) throws Exception {
S>  void main() throws Exception {
S>

S>С аналогом Run.Task разобрался. Но чем это лучше Task в упор не вижу.
Тем, что вся логика параллелизации сосредоточена внутри блока StructuredTaskScope. Вся остальная логика как вглубь coreApi/stockApi/priceApi, так и наружу fetchProduct. Например:

Product coreApi(long id) {
  var d1 = readFromFile(id);
  var d2 = queryDb(id, d1);
  lock();
  var d3 = downloadFromRestApi(id, d2, d1);
  unlock();
  return new Product(d3, d1);
}

Т.е. обычный синхронный код, который ничего про потоки не знает, притом может в любом месте делать любой IO, блокировки, sleep, любые всякие локи, хитрые конкурентные коллекции, и т.п. В случае шарпа все эти методы нужно будет декларировать как async и повсюду расставлять await. САБЖ прочитай!!!

S>·>А что тебе ещё надо? Ты ещё сам приводил ссылку на какую-то статью с десятком примеров кода.
S> Там аналога TaskCompletionSource нет. И сам же говоришь, что StructuredTaskScope еще превью.
Можно использовать "newVirtualThreadPerTaskExecutor" и сабмитить таски. Недостаток — приходится говнокодить всякий WhenAll/WhenAny/cancels/results как в шарпе.

S>>>Правда он и будет возвращать Task.
S>>> Для Java должен быть метод двойник возвращающий Future?
S>·>Зачем? Просто Thread.yield()
S>Ну с этим согласен. Хорошо сделали. Но вот StructuredTaskScope с джойнерами не ахти то и читаемо.
Это просто подход обернуть стандартные паттерны параллелизма и потом легко переиспользовать.

S>То есть не вижу особенных выгод по сравнению с Task.
Сабж же.

S>По Task я вижу, что метод асинхронный и могу использовать либо параллельно, либо последовательно через await.
А с виртуальными тредами ты видишь любой метод и можешь использоваьт либо параллельно, либо последовательно без всякого await-шлака.

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

S>·>Зачем тебе асинхронная очередь при наличии виртуальных тредов? Используй обычный BlockingQueue.
S>·>Впрочем, пишется очень похожим образом, если очень надо, используя CompletableFuture.
S> Я не пишу на Java мне интересно как для TaskCompletionSource прикурутить виртуальные потоки.
Ещё раз. Это ортогональные понятия. Для виртуальных потоков task не нужен. Точнее можно создать обычный thread pool и создавать в нём таски, как обычно. Просто этому пулу передаётся фабрика виртуальных потоков, вместо платформенных по дефолту. Но это не является необходимостью, т.к. task-и не нужны для виртуальных потоков, можно использовать обычные примитивы синхронизации и любой блокирующий IO, т.к. наличие миллионов ждущих потоков не будет проблемой.
Более того, потоки — часть рантайма, а не часть ЯП. Т.е. можно не только писать свои удобные библиотеки всякой хитровывернутой многопоточки по своему вкусу, но это всё так же доступно в любом jvm-based языке — scala/kotlin какой-нибудь.

S>

S>static ProductPayload fetchProduct(long id) throws Exception {
S>  void main() throws Exception {
S>

S>С аналогом Run.Task разобрался. Но чем это лучше Task в упор не вижу.
Тем, что вся логика параллелизации сосредоточена внутри блока StructuredTaskScope. Вся остальная логика как вглубь coreApi/stockApi/priceApi, так и наружу fetchProduct. Например:

Product coreApi(long id) {
  var d1 = readFromFile(id);
  var d2 = queryDb(id, d1);
  lock();
  var d3 = downloadFromRestApi(id, d2, d1);
  unlock();
  return new Product(d3, d1);
}

Т.е. обычный синхронный код, который ничего про потоки не знает, притом может в любом месте делать любой IO, блокировки, sleep, любые всякие локи, хитрые конкурентные коллекции, и т.п. В случае шарпа все эти методы нужно будет декларировать как async и повсюду расставлять await. САБЖ прочитай!!!

S>·>А что тебе ещё надо? Ты ещё сам приводил ссылку на какую-то статью с десятком примеров кода.
S> Там аналога TaskCompletionSource нет. И сам же говоришь, что StructuredTaskScope еще превью.
Можно использовать "Executors.newVirtualThreadPerTaskExecutor" и сабмитить таски. Недостаток — приходится говнокодить всякий WhenAll/WhenAny/cancels/results как в шарпе.

S>>>Правда он и будет возвращать Task.
S>>> Для Java должен быть метод двойник возвращающий Future?
S>·>Зачем? Просто Thread.yield()
S>Ну с этим согласен. Хорошо сделали. Но вот StructuredTaskScope с джойнерами не ахти то и читаемо.
Это просто подход обернуть стандартные паттерны параллелизма и потом легко переиспользовать.

S>То есть не вижу особенных выгод по сравнению с Task.
Сабж же.

S>По Task я вижу, что метод асинхронный и могу использовать либо параллельно, либо последовательно через await.
А с виртуальными тредами ты видишь любой метод и можешь использоваьт либо параллельно, либо последовательно без всякого await-шлака.