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

I>>Правильно, потому что вся эта цепочка становится блокирующей.

EP>Снаружи вызов такой цепочки не блокирующий.

Главное что унутре она вся блокирующая, потому никаких чудес здесь нет.

I>>Блокирующие функции в C# не требуют никаких await, что бы получить аналог такого getline нужны всего лишь нелокальные переходы.

EP>.. которых нет, о чём и речь.

Ага, в C# отменили эвенты, генераторы, ооп-диспетчеризацию и прочие вещи

EP>1. Если цепочка будет сделана на явных await'ах, и async'ах, вместо спрятанных yield'ов — то внезапно это становится асинхронщинной?

У тебя цепочка вся напрочь блокирующая, толко вызывается через неблокирующую короутину. Мне нужно сделать ровно то же — унутре все блокироваться, а снаружи async

EP>2. Какая разница какой именно термин? С использованием stackful coroutine так можно сделать, а с stackless-like (await, one-level yield) — нет.



Одно из двух,
или "в C# отменили эвенты, генераторы, ооп-диспетчеризацию и прочие вещи"
или ты хочешь кооперативную многозадачность (непонятно на каком основании)

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

EP>>1. Если цепочка будет сделана на явных await'ах, и async'ах, вместо спрятанных yield'ов — то внезапно это становится асинхронщинной?
I>У тебя цепочка вся напрочь блокирующая, толко вызывается через неблокирующую короутину. Мне нужно сделать ровно то же — унутре все блокироваться, а снаружи async

у тебя будет await в каждом звене цепи если нет, то код в студию

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

I>после того, как врапнется в task, будет вот такое
I>

I>buffer = await Read();
I>

Это понятно))) Но как "врапнуть в task" подобное я как раз и не представляю себе.

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

_>Это понятно))) Но как "врапнуть в task" подобное я как раз и не представляю себе.

Наверное также как и в C++:

#include <iostream>
#include <future>
using namespace std;

template<typename Handler>
void read_cps(Handler h)
{
    h(11);
}

int main()
{
    promise<int> p;
    read_cps([&](int x){ p.set_value(x); });
    cout << p.get_future().get() << endl;
}

(с поправкой на то что операция будет асинхронной, вместо .get() — await, и т.п.)
Task это фактически аналог std::future.

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

_>Это понятно))) Но как "врапнуть в task" подобное я как раз и не представляю себе.

Будет приблизительно так

[DllImport]
static void Read(Buffer buffer, Action<object> callback);

Task<Buffer> Read()
{
   var task = new Task<Buffer>();
   var buffer = new Buffer();

   Read(buffer, () => task.Continue(buffer) );

   return task;
}

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

EP>>>1. Если цепочка будет сделана на явных await'ах, и async'ах, вместо спрятанных yield'ов — то внезапно это становится асинхронщинной?
I>>У тебя цепочка вся напрочь блокирующая, толко вызывается через неблокирующую короутину. Мне нужно сделать ровно то же — унутре все блокироваться, а снаружи async

EP>у тебя будет await в каждом звене цепи если нет, то код в студию

Обычный код вообще без asynс и await. async-await будет только на самом верху.
Похоже, ты забыл что сам по себе getline у тебя блокирующий, потому мне надо сделать ровно то же — унутре православный синхронный код, а снаружи async. То есть, унутре будут обычное нелокальные переходы.
Ну или как вариант, ты все еще ждешь кооперативную многозадчность

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

EP>>у тебя будет await в каждом звене цепи если нет, то код в студию
I>Обычный код вообще без asynс и await. async-await будет только на самом верху.

А смысл от await+async наверху, если внизу обычный код?

I>Похоже, ты забыл что сам по себе getline у тебя блокирующий, потому мне надо сделать ровно то же — унутре православный синхронный код, а снаружи async.

аналог моему getline на C# будет:

msg = await stream.getline();

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

I>>Похоже, ты забыл что сам по себе getline у тебя блокирующий, потому мне надо сделать ровно то же — унутре православный синхронный код, а снаружи async.

EP>аналог моему getline на C# будет:
EP>

EP>msg = await stream.getline();
EP>

EP>

Это чушь. Твой getline БЛОКИРУЮЩИЙ. Какая у него унутре неонка, то есть, диспетчеризация, вообще не имеет никакого значения. В твоем примере есть кооперативная многозадачность ? Ни разу. Чего ты еще хочешь ?
Соответсвенно нужен просто блокирующий вызов getline безо всяких авайтов, который через нелокальные переходы вытащит все нужные данные.

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

I>Будет приблизительно так

I>

I>[DllImport]
I>static void Read(Buffer buffer, Action<object> callback);

I>Task<Buffer> Read()
I>{
I>   var task = new Task<Buffer>();
I>   var buffer = new Buffer();

I>   Read(buffer, () => task.Continue(buffer) );

I>   return task;
I>}
I>

Что-то я не вижу тут http://msdn.microsoft.com/en-us/library/dd321424.aspx ни конструктора без параметров, ни функции Continue. А так бы да, это был бы буквально ответ на мой вопрос. )

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

EP>(с поправкой на то что операция будет асинхронной, вместо .get() — await, и т.п.)
EP>Task это фактически аналог std::future.

Task то действительно аналог future. А вот аналога promise я как-то не вижу...

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

_>Task то действительно аналог future. А вот аналога promise я как-то не вижу...

О, хотя я тут полистал msdn — на самом деле есть аналог по имени TaskCompletionSource. Так что действительно в точности как на C++ выходит. Странно только что Ikemefula не в курсе про него был, хотя такой защитник C#'a...

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

_>>Task то действительно аналог future. А вот аналога promise я как-то не вижу...

_>О, хотя я тут полистал msdn — на самом деле есть аналог по имени TaskCompletionSource. Так что действительно в точности как на C++ выходит. Странно только что Ikemefula не в курсе про него был, хотя такой защитник C#'a...

Я пока что не пишу на C# а tpl не знаю досконально. В .net не требуется знать все методы всех классов

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

_>Task то действительно аналог future. А вот аналога promise я как-то не вижу...

Не в курсе, чего ты имеешь ввиду под future, но Task может использоваться и как промис, собственно до await их так и юзали.

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

_>Что-то я не вижу тут http://msdn.microsoft.com/en-us/library/dd321424.aspx ни конструктора без параметров, ни функции Continue. А так бы да, это был бы буквально ответ на мой вопрос. )

попутал по привычке, ContinueWith видишь ?

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

I>попутал по привычке, ContinueWith видишь ?

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

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

I>>попутал по привычке, ContinueWith видишь ?

_>Так оно совершенно другую задачу делает, а не завершает задачку, как у тебя в примере. Это даже если забыть что у Task нет конструкторов по умолчанию.

А у меня в примере он и не завершает задачу

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

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

EP>>>1. Если цепочка будет сделана на явных await'ах, и async'ах, вместо спрятанных yield'ов — то внезапно это становится асинхронщинной?
I>>У тебя цепочка вся напрочь блокирующая, толко вызывается через неблокирующую короутину. Мне нужно сделать ровно то же — унутре все блокироваться, а снаружи async

EP>у тебя будет await в каждом звене цепи если нет, то код в студию

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

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

I>А у меня в примере он и не завершает задачу

Эээ ContinueWith принимает в качестве параметра Action. А у тебя в примере он принимает Buffer.

Вообще не пойму чего ты отмазываешься то. Ну не знал и ладно. Я уже сам обнаружил что в принципе на C# можно записать подобный код, с помощью функции TaskCompletionSource.SetResult (вместо твоего Continue). Т.е. в принципе на C# можно писать код подобный примерам Evgeny.Panasyuk'а, хотя и более многословным и неэффективным (в смысле накладных расходов) способом.

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

I>>попутал по привычке, ContinueWith видишь ?

_>Так оно совершенно другую задачу делает, а не завершает задачку, как у тебя в примере. Это даже если забыть что у Task нет конструкторов по умолчанию.

Мне некогда было смотреть, какой метод может сорганизовать ожидаемый объект, потому сделал "кабутта" промис.

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

_>Эээ ContinueWith принимает в качестве параметра Action. А у тебя в примере он принимает Buffer.

Это дело десятое.

_>Вообще не пойму чего ты отмазываешься то. Ну не знал и ладно. Я уже сам обнаружил что в принципе на C# можно записать подобный код, с помощью функции TaskCompletionSource.SetResult (вместо твоего Continue). Т.е. в принципе на C# можно писать код подобный примерам Evgeny.Panasyuk'а, хотя и более многословным и неэффективным (в смысле накладных расходов) способом.

я раза три или четыре сказал, что не знаю тонкостев