Ответа, в принципе, так и нет. Если результат выполнения Task-а возвращается не в место вызова, то как это вообще может работать?

что значит "не в место вызова", ну?

что значит "не в место вызова", ну?

Ну а что значит не в контекст?

await Task.Run(() => { this.loadAction?.Invoke(this); }); Что будет происходить при выполнении этого кода, поясните плз. Если я пишу this.loadAction(this), вылезает ComException. Если пишу чз Invoke, эксепшн не вылезает. Почему? Invoke данный метод в мейнтреде дёргает? Но судя по тому, что изменения UI в loadAction вызывают опять же ComException, вроде бы это не мейн тред. Почему в этом случае await Task.Run(() => { this.loadAction(this); }); падение, а в случае выше — нет?

https://twitter.com/rauchg/status/842950503709327360 кто нить в курсе?

@Hi10pH264 у тя есть тред1 и есть тред2, они отличаются каким-то контекстом. если скопировать весь контекст из тред1 в тред2, чем тебе это не место вызова?

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

работает сложно - это 100%, надо знать подноготную

А. Или я там await писал...

смотри, ещё раз, на пальцах: у тебя есть await. Весь метод разбивается на до и после. то что до - выполняется сразу, потом УПРАВЛЕНИЕ возвращается. Когда таск завершается - второй методо передаётся в SyncronizationContext, который был захвачен в первом методе. Этот synchronizationContext запускает этот метод (второй) на том потоке, на котором был запущен первый метод.

это в случае НЕ консольного приложения, когда есть SynchonizationContext и ConfigureaAwait(true) (по умолчанию)

смотри, ещё раз, на пальцах: у тебя есть await. Весь метод разбивается на до и после. то что до - выполняется сразу, потом УПРАВЛЕНИЕ возвращается. Когда таск завершается - второй методо передаётся в SyncronizationContext, который был захвачен в первом методе. Этот synchronizationContext запускает этот метод (второй) на том потоке, на котором был запущен первый метод.

То есть метод завершается, а потом как-то возобновляется с места await?

Есть вообще какая-нибудь статья, где написано вообще всё о том, как работает async/await? Хоть в 200 страниц, но чтобы всё расписано было.

ildasm.exe

ildasm.exe

не смешно

await Task.Run(() => { this.loadAction?.Invoke(this); }); Что будет происходить при выполнении этого кода, поясните плз. Если я пишу this.loadAction(this), вылезает ComException. Если пишу чз Invoke, эксепшн не вылезает. Почему? Invoke данный метод в мейнтреде дёргает? Но судя по тому, что изменения UI в loadAction вызывают опять же ComException, вроде бы это не мейн тред. Почему в этом случае await Task.Run(() => { this.loadAction(this); }); падение, а в случае выше — нет?

эти фрагменты кода тока null propagetion отличаются

эти фрагменты кода тока null propagetion отличаются

да, сорян я await там где не надо писал и вылетала ошибка попутно всплыл другой вопрос:

То есть метод завершается, а потом как-то возобновляется с места await?

да, просто студия от тебя ээто скрывает когда ты идёшь по F10

public void Main() { this.DoStuff(); } private async void DoStuff() { await PerformTask; } Вот при таком коде ПерформТаск будет выполняться в главном потоке же?

Есть вообще какая-нибудь статья, где написано вообще всё о том, как работает async/await? Хоть в 200 страниц, но чтобы всё расписано было.

рихтера почитай. но я хз, чо не ясно, если ты представил себе очереди, где эти задачи выполняются

Чтобы выполнить таск в треде из ThreadPool, надо Task.Run(() => { PerformTask(); });?

да не

Ну и ещё раз попробую пример тот написать. Мы в async методе, который вызван откуда-то, например из Parallel.For(); В нём мы достигаем вызова с await, следующей строкой используется результат. Вот в момет достижения await происходит понимание, что выполнение затянулось и происходят неочевидные вещи. Какие? // Управление возвращается обратно, потом по сигналу завершения Awaitable метод продолжается. Но он уже вернул управление. Или это не return и он висит где-то в ожидании? Или пересоздаётся? Вот что вообще происходит, когда встречается Awaitable, которое не сразу возвращает значение?

@Worldbeater если ты не предпримешь дополнительных усилий у тебя любой правильно написанный таск улетит на работу в стандартный шедулер

да, просто студия от тебя ээто скрывает когда ты идёшь по F10

Но при всём этом это нужно учитывать. Это как-то неправильно, наверное?..

Ну и ещё раз попробую пример тот написать. Мы в async методе, который вызван откуда-то, например из Parallel.For(); В нём мы достигаем вызова с await, следующей строкой используется результат. Вот в момет достижения await происходит понимание, что выполнение затянулось и происходят неочевидные вещи. Какие? // Управление возвращается обратно, потом по сигналу завершения Awaitable метод продолжается. Но он уже вернул управление. Или это не return и он висит где-то в ожидании? Или пересоздаётся? Вот что вообще происходит, когда встречается Awaitable, которое не сразу возвращает значение?

а что у параллер.фор есть совсемтимая с таском сигнатура?

а что у параллер.фор есть совсемтимая с таском сигнатура?

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

да никакой не итерацией

параллел.фор принимает на вход параметры, создает N традов и начинает на них выполнять операции

это такое высокоуровневое описание. внутри он исполняет лямбды на пуле, емнип

параллел.фор принимает на вход параметры, создает N традов и начинает на них выполнять операции

Я понимаю, но вопрос не в этом.

ты какбэ кад прикладывай, а то хз, чо ты пытаешься представить

https://referencesource.microsoft.com/#mscorlib/system/threading/Tasks/Parallel.cs,0a55781a1c82cafe

внутри тоже таски, хоть и непубличные

private static async Task<int> AsyncRequest() { await Task.Delay(1000); return 10; } private static async Task<int> AsyncMethod(int id) { int res = await AsyncRequest(); // What's going on from here? res *= id; return res; } static void Main(string[] args) { Parallel.For(0, 10, i => { Console.WriteLine(string.Format("Requesting number from {0}", i)); int Res = Task.Run(async () => await AsyncMethod(i)).Result; Console.WriteLine(string.Format("Requested number: {0}. From: {1}", Res, i)); }); Console.Read(); }

Ну и ещё раз попробую пример тот написать. Мы в async методе, который вызван откуда-то, например из Parallel.For(); В нём мы достигаем вызова с await, следующей строкой используется результат. Вот в момет достижения await происходит понимание, что выполнение затянулось и происходят неочевидные вещи. Какие? // Управление возвращается обратно, потом по сигналу завершения Awaitable метод продолжается. Но он уже вернул управление. Или это не return и он висит где-то в ожидании? Или пересоздаётся? Вот что вообще происходит, когда встречается Awaitable, которое не сразу возвращает значение?

Примерный эквивалент того, что здесь.

Вместо AsyncRequest поставить какой-нибудь REST запрос и разбор ответа.

var http = new HttpClient(); var response = await http.GetAsStringAsync("yobaURL").ConfigureAwait(false); return Parse(response) ?

На уровне. Насчёт .ConfigureAwait(false) не уверен.

Не против узнать оба варианта.

в смысле

Как будет с ним и без него.

ну протестируй. так-то если тебе надо вернуться в оригинальное место, то тебе надо дожидаться таску, которая оборачивает эти строчки

сам помнимаешь, что await без контекста async не заюзать

Как я протестирую, если дебаггер не показывает как оно работает?

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

вот давай самое простое

создай UI приложение и повесь там на онБоттонКлик 100500 задач, которые просто засыпают с разным (но небольшим сроком паячки)

Снова всё не по теме. У меня вопрос конкретно в том месте, где написан комментарий. Я бы написал, что мне не важно, откуда вызван этот метод, но, похоже, важно.

какой комментарий?

private static async Task<int> AsyncRequest() { await Task.Delay(1000); return 10; } private static async Task<int> AsyncMethod(int id) { int res = await AsyncRequest(); // What's going on from here? res *= id; return res; } static void Main(string[] args) { Parallel.For(0, 10, i => { Console.WriteLine(string.Format("Requesting number from {0}", i)); int Res = Task.Run(async () => await AsyncMethod(i)).Result; Console.WriteLine(string.Format("Requested number: {0}. From: {1}", Res, i)); }); Console.Read(); }

// What's going on from here?

бля, постите кад на пастин или гист

твоя задача падает запускается и падает в пул

http://pastebin.com/Sw7zsimz

когда она закончится шедулится еще одна задача

res *= id; return res в вызывающем контексте

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

Слишком кратко, не понятно.

https://www.youtube.com/watch?v=p6erF2uBQgQ

твоя задача падает запускается и падает в пул

Вот это больше всего непонятно. Что и куда и откуда падает.

https://referencesource.microsoft.com/#mscorlib/system/threading/Tasks/Task.cs,5885

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

Изначально таск попал в пул, где попал в поток. Потом идёт строка с await. 1. Куда отправляется (и где исполняется) Request. 2. Что происходит с методом, пока это происходит. 3. Что происходит с Таском, пока всё это происходит.

потом ее результат вернется в контекст старта (потому что это дефолтное поведение)

какой блять пул, какой блять поток

твоя задача падает запускается и падает в пул

Ну а что здесь написано?

ERROR: S client not available

таск - это замкнутая лямда с параметрами

// What's going on from here?

воу воу, полегче, зачем тебе Paralller.For?

для интереса?

воу воу, полегче, зачем тебе Paralller.For?

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

зачем такая конструкция Task.Run(async () => await AsyncMethod(i)).Result?

почему не написать AsyncMethod(i).Result?

зачем такая конструкция Task.Run(async () => await AsyncMethod(i)).Result?

Чтобы асинхронный метод работал.

Изначально таск попал в пул, где попал в поток. Потом идёт строка с await. 1. Куда отправляется (и где исполняется) Request. 2. Что происходит с методом, пока это происходит. 3. Что происходит с Таском, пока всё это происходит.

1. в шедулер - их может быть много, разных 2. существует в виде продолжения 3. отпралвяется в разные очереди, исполняется, меняет состояние

Так везде написано, что это заставляет вызывающий поток ждать, а await ждёт его освобождения и всё.

не поток

ПРОДОЛЖЕНИЕ

Ну или не поток

я уже 10 раз сказал, что ты бьешь своё флоу выполнения на кучку задач

Можно в самих терминах написать? Я не знаю русских эквивалентов.

которые триггерят друг друга

ты либо читаешь не те треды, либоо неправильно их понимаешь)

Parallel.For(0, 10, i => { Console.WriteLine(string.Format("Requesting number from {0}", i)); int Res = AsyncMethod(i).Result; Console.WriteLine(string.Format("Requested number: {0}. From: {1}", Res, i)); });

Можно в самих терминах написать? Я не знаю русских эквивалентов.

вот перепиши через ContinueWith и всё

смотри что у тебя происходит, тут нет ничего сложного

Оч интересно сегодня в чате

ты запускаешь ParallelFor - он создаёт столько потоков, сколько у тебя логических ядер у процессора

А, ну да, тут же уже потоки создаются, тут действительно Task не нужен.

на каждом из этих потоков вызывается метод, который ты передал, отличаются только параметры (i)

а что у параллер.фор есть совсемтимая с таском сигнатура?

Я изначально таск написал, чтобы проверить.

в моём варианте (без task.run int Res = AsyncMethod(i).Result;) происходит следующее:

код, Console.WriteLine(string.Format("Requesting number from {0}", i)); выполняется в одном из четырёх потоков, котроые создал ParallelFor, затем идёт вызов метода, в том же потоке

@Worldbeater если ты не предпримешь дополнительных усилий у тебя любой правильно написанный таск улетит на работу в стандартный шедулер

А простой await Task.Run(() => { }); разве не в треде из ThreadPool выполняется? UI же запрещают пинать из этой лямбды, обосновывая это тем, что поток другой.

(можно ли считать, что P.F заменяет T.R в данном случае?)

дальше когда вызывается Task.Delay(1000) УПРАВЛЕНИЕ возвращается обратно и вызывается геттер свойства Result

(можно ли считать, что P.F заменяет T.R в данном случае?)

да

А простой await Task.Run(() => { }); разве не в треде из ThreadPool выполняется? UI же запрещают пинать из этой лямбды, обосновывая это тем, что поток другой.

выплнится на стандартном пуле. иначе зачем нужна эта конструкция

А простой await Task.Run(() => { }); разве не в треде из ThreadPool выполняется? UI же запрещают пинать из этой лямбды, обосновывая это тем, что поток другой.

Через BeginInvoke можно пинать