Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Как не работает? То есть по твоему до await'а асинхронного кода вообще не было?
Очень просто, удали async/await и попробуй хотя бы скомпилировать, потом приходи сюда.
I>>Вот и покажи эту асинхронщину на короутинах. Забудь про MesageBox, TcpStream и тд. Сделай что нибудь внятное, ну хоть Thread.Sleep() если ничего в голову не приходит.
EP>Покажи версию без корутин на C++ — я её переделаю на корутины. А то ты опять будешь кричать что это не "асинхронщина".
Примерно так:
int handler(n)
{
::Sleep(n);
int i = rnd();
::Sleep(n);
return i;
}
thread([]{PostMessage(handler(5000));});
I>>Он работает и без короутин, потому ничего не демонстрирует, вообще.
EP>Асинхронный код на C# можно писать без await/async
Переписать — можно. Можно даже на ассемблере все переписать.
Здравствуйте, AndrewVK, Вы писали:
V>>Но когда они вникают в подробности конкретного участка, поверь, их точно так же интересуют точные типы.
AVK>Отучайся говорить за всех. Лично я первое, что делаю при ковырянии чужого кода — Full Cleanup, который, в числе прочего, заменяет все типы в декларациях на var.
Мало ли, что лично ты делаешь? Например, банальная замена беззнакового целого на знаковое иногда порождает интересные эффекты. Я предпочитаю видеть точные целочисленные типы, хотя бы потому, что они отличаются лишь ограничениями в реализации.
Здравствуйте, Ikemefula, Вы писали:
I>Ну значит UI Loop из моего примера вызовется чудом, например сканированием адресного пространства на предмет наличия ::GetMessage и ::TranslateMessage или, как вариант, короутина догадается WinMain вызвать.
Тю, блин, теперь понятно, что ты там всё время спросить пытаешься. )))
Жесть!
Давай лучше я тебя спрошу:
— что такое короутина?
— надо ли её вызывать "откуда-то" или она работает "сама по себе"?
Здравствуйте, Ikemefula, Вы писали:
I>Теперь мы пришли к выводу, что надо патчить Message Pump. I>::MessageBox() — вот эта функция похерит всю твою асинхронность по той простой причине, что запускает message pump и ничего не знает про твой RunAll
Угу, но это зависит от организации асинхронности IO. Если асинхронность сделана на completion routine, то прекрасно будет работать из того же потока. А если на основе completion ports, то в любом случае для асинхронных операций нужен пул потоков (или минимум один дополнительный поток), но в этом случае твои вопросы сразу отпадают — будет обычное неблокирующее перекидывание задач м/у очередями в потоках.
I>Теперь задачка посложнее, представь себе, что у тебя нет доступа к Message Pump, как заставить работать твою асинхронность ?
Курить completion routines. Чудес не бывает. Дотнет "унутре" тоже как-то реализован.
Именно так. В крайнем случае, если где-то древний код использует GUI-loop без реакции на alertable IO, то вешается хук, который перехватывает этот loop.
I>И похоже, что ваша хваленая асинхронность будет дико лагать, т.к. сильно зависит от частоты эвентов в системе и целой кучи других факторов.
Это ты не туда смотришь. Которутины — лишь кубики Лего, из которых можно собрать произвольную модель. Для твоих требований надо прыгать на alertable IO. При том, что это будет несколько лишних строк кода кода... этот код однократен для любых проектов с такой моделью. Кароч, это C++ way, — лепи себе нужную модель. В т.ч. ту, к которой конкртено ты привык, например, как в дотнете.
Здравствуйте, Ikemefula, Вы писали:
I>Ты используешь цикл выборки сообщений для своих целей особо маргинальным способом. Если не дай бог приложение где нибудь покажет MessageBox или модальную форму, твой маргинальный способ резко закончится.
В каком смысле закончится? Как только MessageBox закроется, то всё отработает как положено. И это весьма логично для многих задач. Ну и в любом случае это особенность данной конкретной реализации. Если очень хочется что бы оно работало и внутри messagebox'ов, то можно например завести таймер и вызывать RunAll в его обработчике вместо главного цикла. Будет работать без проблем.
Да, и всё вышеописанное касается исключительно реализации поддерживающей однопоточный режим! Если же сделать реализацию исключительно для многопоточного варианта (как я уже показывал, через std::async), то все эти проблемы вообще полностью пропадают так что будет работать где угодно без всяких таймеров и не трогая главный цикл. Собственно там уже даже этот пул короутин вообще не нужен — можно держать ссылку на самого себя. Просто подобная реализация возможна и в C#, так что обсуждать её было не особо интересно в отличие от однопоточного случая, которым в C# уже хуже... )))
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Mazay, Вы писали:
M>>В смысле "нужный интерфейс"? То есть код метода нарезается на несколько методов, которые потом дёргаются при наступлении соответствующих асинхронных событий? Так? S>Примерно так. Метод превращается в state-machine, которую на более отсталых языках надо выписывать вручную.
Проблемы там начинаются при вложении этих async, а они обычно вложены друг в друга довольно глубоко. Каждый шаг внешнего автомата вызывает по цепочке кучу шагов внутренних "матрешек". Дешевле уже переключить фибер сразу в нужное место.
Здравствуйте, vdimas, Вы писали:
V>Проблемы там начинаются при вложении этих async, а они обычно вложены друг в друга довольно глубоко. Каждый шаг внешнего автомата вызывает по цепочке кучу шагов внутренних "матрешек". Дешевле уже переключить фибер сразу в нужное место.
Кстати да, хорошее замечание: каждый вызов цепочки stackless coroutine это O(N), а stackful coroutine — O(1).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Теперь мы пришли к выводу, что надо патчить Message Pump. I>>::MessageBox() — вот эта функция похерит всю твою асинхронность по той простой причине, что запускает message pump и ничего не знает про твой RunAll
V>Угу, но это зависит от организации асинхронности IO.
А ты похоже не читатель — обсуждается предложеный вариант, а не любой. Дальше скипнул — смысла нет. Хочешь показать чего интересного — давай свой код.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>Ты используешь цикл выборки сообщений для своих целей особо маргинальным способом. Если не дай бог приложение где нибудь покажет MessageBox или модальную форму, твой маргинальный способ резко закончится.
_>В каком смысле закончится? Как только MessageBox закроется, то всё отработает как положено. И это весьма логично для многих задач.
Для каких то задач MessageBox не критичен, он долго не висит. А скажем DoModal обычно висит долго. Юзеру не понравится, что пока он раотает в формочке, фоновый процессинг висит.
>Если очень хочется что бы оно работало и внутри messagebox'ов, то можно например завести таймер и вызывать RunAll в его обработчике вместо главного цикла. Будет работать без проблем.
Будет. Только по таймеру внезапно время отклика уменьшается и все преимущества перед stackless сходят на нет.
_>Да, и всё вышеописанное касается исключительно реализации поддерживающей однопоточный режим! Если же сделать реализацию исключительно для многопоточного варианта (как я уже показывал, через std::async), то все эти проблемы вообще полностью пропадают так что будет работать где угодно без всяких таймеров и не трогая главный цикл. Собственно там уже даже этот пул короутин вообще не нужен — можно держать ссылку на самого себя. Просто подобная реализация возможна и в C#, так что обсуждать её было не особо интересно в отличие от однопоточного случая, которым в C# уже хуже... )))
А здесь, как выяснили, нужны все аналоги async/await
Здравствуйте, vdimas, Вы писали:
V>>>Но когда они вникают в подробности конкретного участка, поверь, их точно так же интересуют точные типы. AVK>>Отучайся говорить за всех. Лично я первое, что делаю при ковырянии чужого кода — Full Cleanup, который, в числе прочего, заменяет все типы в декларациях на var. V>Мало ли, что лично ты делаешь?
Тогда поясни — либо "их" это все таки несколько более узкий круг, чем заявлено, либо я не принадлежу к "более опытным разработчикам".
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, Ikemefula, Вы писали:
I>Для каких то задач MessageBox не критичен, он долго не висит. А скажем DoModal обычно висит долго. Юзеру не понравится, что пока он раотает в формочке, фоновый процессинг висит.
Ну собственно говоря "однопоточную асинхронщину" явно не нет смысла применять для организации фоновых процессов. Это скорее средство реорганизации обычного линейного кода. Например в случае сервера (с большим числом соединений, так что удобная техника "по потоку на соединение" уже не подходит) надо писать некий линейный код опрашивающий массив сокетов и что-то там делающий дальше. А с помощью coroutine это полностью переделывается в набор виртуальных потоков. Ну и понятно что в таком случае нет никакого главного ui цикла, а остаётся только цикл while(!AsyncPool.IsEmpty()) AsyncPool.RunAll();.
I>Будет. Только по таймеру внезапно время отклика уменьшается и все преимущества перед stackless сходят на нет.
Да это вообще кривое решение, но оно демонстрирует что в C++ у нас есть десятки их видов на любой вкус — конструируешь сам. В отличие от...
I>А здесь, как выяснили, нужны все аналоги async/await
Ну да, реализация многопоточной асинхронщины что средствами C# (async/await), что средствами C++ (std::async, boost.coroutines) выглядят в итоге практически неотличимо.
Здравствуйте, alex_public, Вы писали:
_>Ну собственно говоря "однопоточную асинхронщину" явно не нет смысла применять для организации фоновых процессов. Это скорее средство реорганизации обычного линейного кода. Например в случае сервера (с большим числом соединений, так что удобная техника "по потоку на соединение" уже не подходит) надо писать некий линейный код опрашивающий массив сокетов и что-то там делающий дальше. А с помощью coroutine это полностью переделывается в набор виртуальных потоков. Ну и понятно что в таком случае нет никакого главного ui цикла, а остаётся только цикл while(!AsyncPool.IsEmpty()) AsyncPool.RunAll();.
Посмотри в nginx, там как то живут без короутин Для того, что бы комфортно работать с асинхронщиной, нужно добиваться локальности изменений под конкретную задачу, а stackfull короутины дают прямо противоположный результат.
_>Да это вообще кривое решение, но оно демонстрирует что в C++ у нас есть десятки их видов на любой вкус — конструируешь сам. В отличие от...
Ну то есть решение кривое — я об этом и говорю.
I>>А здесь, как выяснили, нужны все аналоги async/await
_>Ну да, реализация многопоточной асинхронщины что средствами C# (async/await), что средствами C++ (std::async, boost.coroutines) выглядят в итоге практически неотличимо.
Теоретически. На практике надо следить руками, чего где надо вызывать и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Посмотри в nginx, там как то живут без короутин Для того, что бы комфортно работать с асинхронщиной, нужно добиваться локальности изменений под конкретную задачу, а stackfull короутины дают прямо противоположный результат.
Конечно без проблем можно и без них. Собственно говоря coroutine — это всего лишь своеобразный синтаксический сахар. Правда очень модный. С его помощью мы можем переписать такой код:
И при этом реальная последовательность исполнения не изменится — на мой взгляд самое оно для подобных задач. Но именно что для подобных, а не для скачивания файла в фоне от GUI. Для последнего надо во-первых отдельный поток, а во-вторых нафиг не нужен подобный синтаксический сахар — он только запутывает на пустом месте. Так что для скачивания файла в фоне мне и C# async/await сахар тоже совсем не нравится...
Здравствуйте, Ikemefula, Вы писали:
V>>Угу, но это зависит от организации асинхронности IO.
I>А ты похоже не читатель — обсуждается предложеный вариант, а не любой.
Это ты не читатель:
Это ты не туда смотришь. Которутины — лишь кубики Лего, из которых можно собрать произвольную модель.
I>Дальше скипнул — смысла нет. Хочешь показать чего интересного — давай свой код.
Дык, самое интересное, — прикладной код, тебе уже показали. Схематичную реализацию такого фреймворка тебе тоже уже показали. Показали с целью продемонстрировать, откуда вызываются короутины. Там должно было уже давно быть понятно даже тому, что первый раз про асинхрнность слышит...
А теперь ты пытаешься требовать подробную реализацию фреймворка, который будет работать, так же, как дотнете. Посмотри как это сделано в дотнете, делов-то. Там вовсе не 200к кода нужного кода, ес-но.
В виндах существует минимум 3 модели асинхронности, каждая из которых имеет право на жизнь в своих сценариях. Для GUI-потока наиболее естественно — это completion routines. Для серверного приложения — completion ports. Каждая из моделей специфична, но (!!!) практически не влияет на прикладной код. И в этом прелесть.
Здравствуйте, vdimas, Вы писали:
V>Это ты не читатель: V>
V>Это ты не туда смотришь. Которутины — лишь кубики Лего, из которых можно собрать произвольную модель.
Спасибо, капитан ! Я то думал, что короутины дотнета для которых прикручено N апи комбинаторов это кубики лего из которых можно собрать произвольную модель, а на самом деле это апи комбинаторов, из которых можно собрать произвольную модель.
I>>Дальше скипнул — смысла нет. Хочешь показать чего интересного — давай свой код.
V>Дык, самое интересное, — прикладной код, тебе уже показали. Схематичную реализацию такого фреймворка тебе тоже уже показали. Показали с целью продемонстрировать, откуда вызываются короутины. Там должно было уже давно быть понятно даже тому, что первый раз про асинхрнность слышит...
Мне нужен пример не любых короутин, а stackfull. E.P. сделал много заявлений, но кроме синхронного кода ничего и не показал. Если бы alex_public не прикрыл его с фланга, был бы провал.
V>А теперь ты пытаешься требовать подробную реализацию фреймворка, который будет работать, так же, как дотнете. Посмотри как это сделано в дотнете, делов-то. Там вовсе не 200к кода нужного кода, ес-но.
Разумеется, а то первый же пример stackfull замораживал UI
V>В виндах существует минимум 3 модели асинхронности, каждая из которых имеет право на жизнь в своих сценариях. Для GUI-потока наиболее естественно — это completion routines. Для серверного приложения — completion ports. Каждая из моделей специфична, но (!!!) практически не влияет на прикладной код. И в этом прелесть.
I>Спасибо, капитан ! Я то думал, что короутины дотнета для которых прикручено N апи комбинаторов это кубики лего из которых можно собрать произвольную модель,
Увы, нельзя произвольную.
I>а на самом деле это апи комбинаторов, из которых можно собрать произвольную модель.
Только stackless, со всеми торчащими наружу кишками/модификаторами/ограничениями в сценариях и складыванием такого кода в глубокие "матрешки" дергающих друг друга конечных автоматов.
I>Мне нужен пример не любых короутин, а stackfull. E.P. сделал много заявлений, но кроме синхронного кода ничего и не показал. Если бы alex_public не прикрыл его с фланга, был бы провал.
Нет там никакого синхронного кода. Ты неоднократно прямо спросил кто и откуда вызывает короутины — тебе схематично показали, без лишней воды. А подробности — это подробности механики шедуллера. Например, в дотнете GUI-циклы крутятся обязательно так, чтобы обрабатывать события alertable IO. Впрочем, я на это уже обращал твоё внимание, когда ты пытался спекулировать на приведенном сниппете. Но, опять же, и это необязательно. Можно ведь построить модель с дополнительным потоком, где будет вся асинхронность, отвязанная от цикла GUI, в который передавать события банально чеез PostThreadMessage. Но и это не важно. Потому что это уже те подробности, которые ты на тот момент не спрашивал, а которые спрашивал — сделал вид, что не заметил. В общем, моделей диспетчеризации событий может быть куча. А у асинхронности должен быть только один признак — неблокируемость операций.
V>>А теперь ты пытаешься требовать подробную реализацию фреймворка, который будет работать, так же, как дотнете. Посмотри как это сделано в дотнете, делов-то. Там вовсе не 200к кода нужного кода, ес-но.
I>Разумеется, а то первый же пример stackfull замораживал UI
Если ввод-вывод неблокирующий, то он никак не замораживает UI. Именно так реализуют асинхронность без вообще каких-либо дополнительных потоков.
V>>В виндах существует минимум 3 модели асинхронности, каждая из которых имеет право на жизнь в своих сценариях. Для GUI-потока наиболее естественно — это completion routines. Для серверного приложения — completion ports. Каждая из моделей специфична, но (!!!) практически не влияет на прикладной код. И в этом прелесть.
I>Правильно и все три работают без короутин.
Не надо валить всё в кучу. ))
Это модели диспетчеризации событий/задач, отличающиеся используемым низлежащим АПИ ОС. А то, что некая задача является "короутиной", диспетчеру должно быть вообще до фени. Пусть выгребает из очереди некий абстрактный Task и запускает его. Короутина — это уже нечто более высокоуровневое, это трюк для выпрямления прикладного автоматного/событийного кода в якобы линейный.
Здравствуйте, alex_public, Вы писали:
_>... Но именно что для подобных, а не для скачивания файла в фоне от GUI. Для последнего надо во-первых отдельный поток,
Кстате, вовсе не надо отдельный поток, если использовать неблокирующий ввод-вывод, либое какие-нить completion routines.
