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

EP>

EP>void task()
EP>{
EP>    MessageBox(0, TEXT("on max"), TEXT(""), MB_OK);
EP>    async_something([]
EP>    {
EP>        MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
EP>    });
EP>}
EP>

EP>Во втором statement'е таск запускает асинхронную обработку, и передаёт лямбду-продолжение как параметр, completion callback — т.е. что делать, когда это something (например download) произойдёт.

То есть, ты предлагаешь локальную задачу растаскивать на 4 разных части ? Я чтото не вижу, как у тебя будет работать скажем скачивание

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

I>Самый высший — это надо контролировать глобальный цикл выборки сообщений или чтото навроде. Этой возможности может и не быть.

Нужен не самый высший, а просто выше.
В C# async'и расползаются транзитивно вверх по callstack'у, с самого нижнего уровня где нужен await, до самого высшего уровня где результата можно не ждать. Назовём все такие уровни "цепочкой async". Верх цепочки — не тоже самое что верх call stack'а, и не тоже самое что самый верхний message pump.
Так вот, в случае stackful coroutine, какой-то специальный код нужен только в самом вверху цепочки и в самом низу, а в случае async/await — по всей цепочке.
Длина цепочки в аналогичном коде и там и там будет одинаковая.

I>Даже так — в общем случае её нет. Любое модальное окно порушит всю твою стройную идею.

Точно также как и модальное окно в неправильном месте async метода в C#.

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

EP>Во втором statement'е таск запускает асинхронную обработку, и передаёт лямбду-продолжение как параметр, completion callback — т.е. что делать, когда это something (например download) произойдёт.

Твой код работает безо всяких короутин. Проверь сам.

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

EP>>Во втором statement'е таск запускает асинхронную обработку, и передаёт лямбду-продолжение как параметр, completion callback — т.е. что делать, когда это something (например download) произойдёт.
I>Твой код работает безо всяких короутин. Проверь сам.

Так я код с корутинами специально пока не показываю, а то ты опять скажешь — всё не так, нет асинхронности, ui замёрз.
В этом коде, без корутин по твоему есть асинхронность? Если есть то я выложу task переписанный на корутинах, без всяких изменений message pump.

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

I>Самый высший — это надо контролировать глобальный цикл выборки сообщений или чтото навроде. Этой возможности может и не быть. Даже так — в общем случае её нет. Любое модальное окно порушит всю твою стройную идею.

Оно и должно порушить (точнее отложить обработку до своего закрытия), если мы хотим обрабатывать результаты в UI потоке. Так будет в любом языке или платформе. И это не ошибка, а следование условиям задачи.

I>Асинхронщина.

ОК. Тогда я признаю что "асинхронщина" действительно постоянно нужна везде. Но тогда ещё пара комментариев на эту тему:

1. Нормальная асинхронщина отлично реализуется без всяких fiber, coroutine, await/async.
2. Люди спокойно программируют подобные вещи уже не первый десяток лет, просто не называя это всякими модными словами. )))

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

V>Но когда они вникают в подробности конкретного участка, поверь, их точно так же интересуют точные типы.

Отучайся говорить за всех. Лично я первое, что делаю при ковырянии чужого кода — Full Cleanup, который, в числе прочего, заменяет все типы в декларациях на var.

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

EP>>

EP>>void task()
EP>>{
EP>>    MessageBox(0, TEXT("on max"), TEXT(""), MB_OK);
EP>>    async_something([]
EP>>    {
EP>>        MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
EP>>    });
EP>>}
EP>>

EP>>Во втором statement'е таск запускает асинхронную обработку, и передаёт лямбду-продолжение как параметр, completion callback — т.е. что делать, когда это something (например download) произойдёт.
I>То есть, ты предлагаешь локальную задачу растаскивать на 4 разных части ?

Какую задачу?
Я показываю пример асинхронного кода, который переписывается на stackful coroutine посредством локальной трансформации.

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

I>Это было давно и неправда.

Он и сейчас пока что на плюсах написан, Розлин ХЗ когда релизнут. И это, кстати, самая большая его проблема.

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

EP>Есть бенчмарки?

Есть бенчмарки про СУБД: https://code.google.com/p/csharp-sqlite/wiki/Benchmarks

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

EP>Какую задачу?
EP>Я показываю пример асинхронного кода, который переписывается на stackful coroutine посредством локальной трансформации.

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

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

I>>Самый высший — это надо контролировать глобальный цикл выборки сообщений или чтото навроде. Этой возможности может и не быть. Даже так — в общем случае её нет. Любое модальное окно порушит всю твою стройную идею.

_>Оно и должно порушить (точнее отложить обработку до своего закрытия), если мы хотим обрабатывать результаты в UI потоке. Так будет в любом языке или платформе. И это не ошибка, а следование условиям задачи.

Как то так выходит, что модальные окна ничего не рушат

_>1. Нормальная асинхронщина отлично реализуется без всяких fiber, coroutine, await/async.

Да, и даже на ассемблере !!!!

_>2. Люди спокойно программируют подобные вещи уже не первый десяток лет, просто не называя это всякими модными словами. )))

Как то незаметно, глядя на замерзания UI и тд и тд и тд

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

EP>Так я код с корутинами специально пока не показываю, а то ты опять скажешь — всё не так, нет асинхронности, ui замёрз.
EP>В этом коде, без корутин по твоему есть асинхронность? Если есть то я выложу task переписанный на корутинах, без всяких изменений message pump.

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

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

EP>Так вот, в случае stackful coroutine, какой-то специальный код нужен только в самом вверху цепочки и в самом низу, а в случае async/await — по всей цепочке.

Покажи.

EP>Длина цепочки в аналогичном коде и там и там будет одинаковая.
I>>Даже так — в общем случае её нет. Любое модальное окно порушит всю твою стройную идею.

EP>Точно также как и модальное окно в неправильном месте async метода в C#.

Если ты влазишь в message pump то любое модальное окно все порушит, потому что создает свой pump. А та проблема про которую ты говоришь высосана из пальца.

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

I>Как то так выходит, что модальные окна ничего не рушат

Дааа? ) Ну давай протестируем следующий C# код:

private async void start()
{
    string result = await new Task(() => Download(args.Url), args.Cancellation);
    MessageBox(result);
}
private void handler(object sender, TaskArgs args)
{
    start();
    MessageBox("На закрываем окно, пока не появится второе!");
}

Вопрос: если мы не закроем первый MessageBox, то какое время нам придётся ждать второго?

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

EP>>Так вот, в случае stackful coroutine, какой-то специальный код нужен только в самом вверху цепочки и в самом низу, а в случае async/await — по всей цепочке.
I>Покажи.

Я уже показывал — код с TcpStream — от запуска корутины до yield'а может быть сколько угодно пользовательских уровней не засорённых асинхронными аретфактами.

EP>>Я показываю пример асинхронного кода, который переписывается на stackful coroutine посредством локальной трансформации.
I>А зачем его переписывать если и так все работает ? ПОкажи внятную задачу.

Без await/async тоже и так всё работает

EP>>Так я код с корутинами специально пока не показываю, а то ты опять скажешь — всё не так, нет асинхронности, ui замёрз.
EP>>В этом коде, без корутин по твоему есть асинхронность? Если есть то я выложу task переписанный на корутинах, без всяких изменений message pump.
I>Неинтересно, у тебя и так все работает. Покажи нормальную задачу, которая иначе как черз долгое ожидание не решается без асинхронщины.

Ты говорил

Автор: Ikemefula
Дата: 25.06.13

что UI вызовется только чудом:

Ну значит UI Loop из моего примера вызовется чудом, например сканированием адресного пространства на предмет наличия ::GetMessage и ::TranslateMessage или, как вариант, короутина догадается WinMain вызвать.

что UI висит

Автор: Ikemefula
Дата: 25.06.13

:

Итого если этот метод висит до получаения результат, то очевидно, что и UI loop висит, а соответсвенно и UI висит. Может короутина догадается что надо сделать луп ? Или догадается вызвать WinMain ?

что корутине нужно знать про event loop:

Аналог чего ? Я не вижу асинхронного кода, ты даже не можешь показать, каким образом короутина узнает про UI loop.

что нужно готовить scheduler

Автор: Ikemefula
Дата: 25.06.13

:

При этом повторяю — нет в короутинах асинхронщины, асинхронщину берет на себя шедулер, который надо еще правильно приготовить, скормить ему набор короутин между которыми он и будет переключаться.

---

Вот полный, рабочий пример, показывающий что все эти утверждения от банального незнания/неумения.
Корутина здесь ничего не знает про UI loop, ничего не висит, UI loop работает без всяких чудес, никакой scheduler готовить не надо, трансформация из обычного кода в код на корутине — полностью локальная

#include <boost/coroutine/all.hpp>
#include <functional>
#include <algorithm>
#include <cstring>
#include <memory>
using namespace std;

#include <windows.h>

function<void()> on_minization;

template<typename F>
void async_something(F f)
{
    on_minization = f;
}

#if 0

void task()
{
    MessageBox(0, TEXT("on max"), TEXT(""), MB_OK);
    async_something([]
    {
        MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
    });
}

#else

void task()
{
    typedef boost::coroutines::coroutine<void()> Coro;
    auto &&red_portal = make_shared<Coro>();
    *red_portal = Coro([=](Coro::caller_type &blue_portal)
    {
        MessageBox(0, TEXT("on max"), TEXT(""), MB_OK);
        async_something( [=]{ (*red_portal)(); } );
        blue_portal();
        MessageBox(0, TEXT("on min"), TEXT(""), MB_OK);
    });
}

#endif


LRESULT CALLBACK window_procedure(HWND hwnd, UINT msg, WPARAM w_param, LPARAM l_param)
{
    switch (msg)
    {
        case WM_DESTROY:
            PostQuitMessage(0);
            return 0;
        case WM_SIZE:
            switch(w_param)
            {
                case SIZE_MAXIMIZED:
                    task();
                    break;
                case SIZE_MINIMIZED:
                    if(on_minization) on_minization();
                    break;
            }
        default:
            return DefWindowProc(hwnd, msg, w_param, l_param);
    }
}

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE, LPSTR, int nCmdShow)
{
    WNDCLASS wincl = {};
    wincl.hInstance = hInstance;
    wincl.lpszClassName = TEXT("SFC");
    wincl.lpfnWndProc = window_procedure;
    RegisterClass(&wincl);

    auto hwnd = CreateWindow(wincl.lpszClassName, TEXT(""), WS_OVERLAPPEDWINDOW, 0, 0, 100, 100, 0, 0, hInstance, 0);
    ShowWindow (hwnd, nCmdShow);

    MSG msg;
    while(GetMessage(&msg, 0, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}

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

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

EP>>>Я показываю пример асинхронного кода, который переписывается на stackful coroutine посредством локальной трансформации.
I>>А зачем его переписывать если и так все работает ? ПОкажи внятную задачу.

EP>Без await/async тоже и так всё работает

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

EP>

EP>При этом повторяю — нет в короутинах асинхронщины, асинхронщину берет на себя шедулер, который надо еще правильно приготовить, скормить ему набор короутин между которыми он и будет переключаться.

Вот и покажи эту асинхронщину на короутинах. Забудь про MesageBox, TcpStream и тд. Сделай что нибудь внятное, ну хоть Thread.Sleep() если ничего в голову не приходит.

EP>

---

EP>Вот полный, рабочий пример, показывающий что все эти утверждения от банального незнания/неумения.
EP>Корутина здесь ничего не знает про UI loop, ничего не висит, UI loop работает без всяких чудес, никакой scheduler готовить не надо, трансформация из обычного кода в код на корутине — полностью локальная
EP>Корутины здесь без синтаксического захара, для наглядности. Выше, на примере TcpStream уже показывал как можно убрать весь шум.

Ты еще тридцать раз запости этот же пример. Он работает и без короутин, потому ничего не демонстрирует, вообще.

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

_>Дааа? ) Ну давай протестируем следующий C# код:

Да, именно так.

_>Вопрос: если мы не закроем первый MessageBox, то какое время нам придётся ждать второго?

Это ДРУГАЯ проблема ! Что характерно, она есть и в твоем случае.

void handler()
{ 
   ::MessageBox(); // пошел новый цикл и вся твоя асинхронщина на короутинах встала колом.
}

А вот такой проблемы с async/await нет.

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

EP>>>>Я показываю пример асинхронного кода, который переписывается на stackful coroutine посредством локальной трансформации.
I>>>А зачем его переписывать если и так все работает ? ПОкажи внятную задачу.
EP>>Без await/async тоже и так всё работает
I>Не работает и даже не компилится, потому что связывание результатов никто не сделает.

Как не работает? То есть по твоему до await'а асинхронного кода вообще не было?

EP>>

EP>>При этом повторяю — нет в короутинах асинхронщины, асинхронщину берет на себя шедулер, который надо еще правильно приготовить, скормить ему набор короутин между которыми он и будет переключаться.

I>Вот и покажи эту асинхронщину на короутинах. Забудь про MesageBox, TcpStream и тд. Сделай что нибудь внятное, ну хоть Thread.Sleep() если ничего в голову не приходит.

Покажи версию без корутин на C++ — я её переделаю на корутины. А то ты опять будешь кричать что это не "асинхронщина".

EP>>Корутина здесь ничего не знает про UI loop, ничего не висит, UI loop работает без всяких чудес, никакой scheduler готовить не надо, трансформация из обычного кода в код на корутине — полностью локальная
I>Ты еще тридцать раз запости этот же пример.

В этом случае я добавил код корутин.

I>Он работает и без короутин, потому ничего не демонстрирует, вообще.

Асинхронный код на C# можно писать без await/async

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

I>Это ДРУГАЯ проблема ! Что характерно, она есть и в твоем случае.

Ну так я правильно понял, что она есть и в C#? ))) Тогда какие претензии к тому коду? )

I>А вот такой проблемы с async/await нет.

Ничего не понял. ) Покажи пример с async/await которому пофиг на открытый MessageBox.

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

I>>Это ДРУГАЯ проблема ! Что характерно, она есть и в твоем случае.

_>Ну так я правильно понял, что она есть и в C#? ))) Тогда какие претензии к тому коду? )

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

Не в асинхронном коде и не в коде который вызывается из асинхронного и не в коде который вызывает асинхронный, а вообще в любом месте.

То есть, в твоем случае надо тупо запретить делать любые MessageBox и модальные окна.

I>>А вот такой проблемы с async/await нет.

_>Ничего не понял. ) Покажи пример с async/await которому пофиг на открытый MessageBox.

Все что ему нужно — работающий message pump. Откуда он будет запускаться — из Main или MessageBox, абсолютно не важно. А вот в твоем случае надо научить тот цикл что в MessageBox/DoModal делать RunAll, иначе твоя асинхронщина не будет работать.