По поводу второго, кстати, я бы взялся заявить, что этот код синхронный.

Из-за того, что операции чтения с диска последовательные?(я спрашиваю, в этом не шарю уже)

Другой вопрос, что у нас не блокируется текущий поток исполнения, и это и называется асинхронностью

Почему?

Потому что вот этот код будет *ждать* завершения параллельной обработки. Гуй-тред повиснет

Представь, что там сто тысяч файлов в списке.

Если сто тыщ файлов, то нужен правильный енумератор

Тред-пул будет параллельно сто тыщ запросов на диск отправлять и ждать, а гуй будет висеть.

Представь, что там сто тысяч файлов в списке.

Точно, но будет параллельным

Если сто тыщ файлов, то нужен правильный енумератор

А хоть с каким энумератором, у него там AsParallel().Any()

Ну AsParallel же настроить можно

В общем, в моей терминологии "асинхронное" — это которое не вешает вызвавший поток.

Скока одновременно, все дела

В общем, в моей терминологии "асинхронное" — это которое не вешает вызвавший поток.

Именно

Ну AsParallel же настроить можно

Нельзя его настроить на fire-and-forget. Ты написал блокирующий Any() — ты блокируешься. Никаких альтернатив.

Просто я не понимаю утверждения про то, что нет потока ожидающего

Потока может не быть в самом простом кейсе при использовании TaskCompletionSource.

Например, Task.Delay не обязан порождать никаких потоков вообще.

Просто я не понимаю утверждения про то, что нет потока ожидающего

https://blog.stephencleary.com/2013/11/there-is-no-thread.html

То, что оно гуй тред не вешает не делает операцию асинхронной

А что тогда?

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

вообще Task это обертка для асинхронной операции

Ну не совсем

только в отличие от F# async она горячая

Task.Run() это тупой запуск кода на потоке из тред пула

Ну не совсем

немного упрощение, соглаен

Task.Run это частный случай

TaskCompletionSource хороший пример

Просто сам Task это более абстрактная вещь, чем Thread. И для асинхронности в том числе

Там раньше же были через события и IAsyncResult паттерны

Просто сам Task это более абстрактная вещь, чем Thread. И для асинхронности в том числе

Ну да. TPL это следующий этап развития

Async patternа

Просто я к тому, что асинхронность это не про Task, а про другое.

Ну если под асинхронностью понимать механизм колбэков, то да, другое

https://msdn.microsoft.com/en-us/library/jj152938(v=vs.110).aspx

Так Task это и есть имплементация кэлбэков но с человеческим лицом

Интересно, какие там внутри примитивы синхронизации

К сожалению их используют в основном для Task.Run и Task.Fatory.StartNew

Так Task это и есть имплементация кэлбэков но с человеческим лицом

+

К сожалению их используют в основном для Task.Run и Task.Fatory.StartNew

А вот и нет, используют для чего потребуется :) Просто большинство нетривиальных реализаций уже есть в BCL или сторонних библиотеках. Поэтому в конечном приложении остаётся только тривиальщина.

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

Например, в стандартной пинговалке или отправлялке емейлов (которая уже deprecated) довольно хитрый код на TaskCompletionSource.

В пинговалке так они там балуются и ансейфом, и GC.KeepAlive и вообще чёрт знает чем.

TaskCompletionSource вообще классная вещь.

С ним такие вещи мутить можно

в Асинке фшарпном кстати тоже такое есть

Async.FromContinuations

TaskCompletionSource вообще классная вещь.

Жалко только что сам Task нельзя создать, а потом установить (как в java completablefutre и всяких др промисах).

Жалко только что сам Task нельзя создать, а потом установить (как в java completablefutre и всяких др промисах).

В смысле нельзя?

Жалко только что сам Task нельзя создать, а потом установить (как в java completablefutre и всяких др промисах).

TaskCompletionSource жи!

var tcs = new TaskCompletionSource();

Ну TaskCompletionSource для это и дан, что нельзя var task = new Task<string>(); task.CompleteSuccess(“hello world”); task.CompleteFailed(new Exception());

tsc.Task

Ну, конкретно так нельзя, но по смыслу на TCS то же самое.

Я и говорю, сущности плодят, когда в др языках это один класс

Я и говорю, сущности плодят, когда в др языках это один класс

мне так кажется нормально что источник таски отделен от самой таски

Я и говорю, сущности плодят, когда в др языках это один класс

В большинстве других языков сделано ещё маргинальнее, не обольщайся :)

Толстоватый наброс

Ну, промисы в жс ты видал, например?

Хоть "старые", на deferred, хоть новые. Там намного больше сущностей.

А жаве таску можно вот так вот закомплитить?

А жаве таску можно вот так вот закомплитить?

Не любую, а только вполне конкретного типа. И наружу ты её выставляешь уже не как Completable, чтоб вызыватель не закомплитил :)

Не любую, а только вполне конкретного типа. И наружу ты её выставляешь уже не как Completable, чтоб вызыватель не закомплитил :)

?

Отличие от нашего варианта минорное, на мой взгляд.

то есть еще и интерфейсы прибабахали

мне вариант с TCS больше нравится

А в жаве любят интерфейсы, это норм

У них просто так заведено, а у нас эдак.

Не любую, а только вполне конкретного типа. И наружу ты её выставляешь уже не как Completable, чтоб вызыватель не закомплитил :)

Никогда такого не делал (пишу на java/kotlin > 3 лет). Если вызыватель ее закомлитит сам, то он не очень умный человек (мягко выражаясь).

Как думаете, что лучше, Exception или Result?

Result

Result вроде как обязывает делать обработку ошибок, но код получается громоздковатым

Ну он скорее подталкивает более полно описывать предметную область

И цепочку выражений сделать не получится

Или получится?

Как думаете, что лучше, Exception или Result?

Ха, смотря где.

И даже не совсем так.

Короче

Есть статья на тему

Мне кажется, что использование или неиспользование непроверяемых исключений зависит от твоей стратегии.

http://fsharpforfunandprofit.com/rop/

Если ты решил, что какие-то ошибки (ну, скажем, в конфигурации проекта) являются фатальными и надо падать — то ты в том модуле забиваешь на Result и плюёшься исключениями.

Но если у тебя ошибки — часть доменной логики, то тогда только Result.

В целом, всегда может прилететь НЁХ и все сломать

Но ее лучше ловить централизованно, по идее

Просто при использовании исключений часто есть соблазн использовать их как часть control flow

А потом и не как часть :)

И цепочку выражений сделать не получится

как раз с резалтом цепочка получается. fun() |> Result.map() |> Result.bind() |> Result.mapError() и т.д.

Если ты решил, что какие-то ошибки (ну, скажем, в конфигурации проекта) являются фатальными и надо падать — то ты в том модуле забиваешь на Result и плюёшься исключениями.

?

Result -- это не очень хорошо.

Лучше специализированные DU для ошибок, которые будут описываться в рамках доменной логики.

@Dolfik https://eiriktsarpalis.wordpress.com/2017/02/19/youre-better-off-using-exceptions/

А кто мне за fable может рассказать?

А что тебе рассказать? Они интегрировались в dotnet и теперь проект создается в 2 команды http://fable.io/blog/Paket-integration.html

Ждем релиза 1.0

Под обычным дотнетом они живут, кстати, или только под корой?

Лучше специализированные DU для ошибок, которые будут описываться в рамках доменной логики.

Аха, тут ты прав.

Под обычным дотнетом они живут, кстати, или только под корой?

Под кором точно (netstandard 1.6), а про обычный не знаю

@Dolfik https://eiriktsarpalis.wordpress.com/2017/02/19/youre-better-off-using-exceptions/

Ну вот это точно содомия : type MoneyWithdrawalResult = | Success of amount:decimal | InsufficientFunds of balance:decimal | CardExpired of DateTime | UndisclosedFailure правильно - type Error = | InsufficientFunds of decimal | CardExpired of DateTime | UndisclosedFailure type MoneyWithdrawalResult = | Ok of decimal | Err of Error ибо хоть 2) - унификация а 1) неподдерживаемый велосипед

Если ты решил, что какие-то ошибки (ну, скажем, в конфигурации проекта) являются фатальными и надо падать — то ты в том модуле забиваешь на Result и плюёшься исключениями.

Да, это концепция panic, очень популярная сейчас. Я теперь только так делаю, а бросателям эксепшенов из внешних либ шлём луч зла