Здравствуйте, Аноним, Вы писали:

А>время на переключение потоков тратиться (а это доп. ресурсы, кстати).
Там, в основном, managed threads в юзерских приложениях — их "переключение" по сути бесплатно

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

V>>>Ну так покажи как это будет выглядеть. Любопытно.
G>>Ты быстрее сам примеры в сети найдешь, чем я буду писать.

V>Разве? Мне был интересен момент декларативной подписки на события для заданного примера.

Это для событий созданных НЕ на основе EventHandler\EventHandler<Args>
http://rxwiki.wikidot.com/101samples#toc6

Вот тут пример с событием на основе EventHandler<Args>
http://synchronicity-life.blogspot.com/2011/12/how-to-use-fromeventpattern-in-reactive.html

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

Спасибо, любопытно, но не торкнуло.

G>Это для событий созданных НЕ на основе EventHandler\EventHandler<Args>
G>http://rxwiki.wikidot.com/101samples#toc6

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

К тому же, это просто описание адаптера, который для задачи топикстартера лишь промежуточный. В конечный адаптер надо еще завернуть предикат + вызов метода.


G>Вот тут пример с событием на основе EventHandler<Args>
G>http://synchronicity-life.blogspot.com/2011/12/how-to-use-fromeventpattern-in-reactive.html

Такая же точно техника и точно так же типы целиком указывать надо.

В общем, эта задача решалась бы банально, если бы не надо было городить такие обертки-адаптеры под нормальный асинхронный паттерн. А чтобы их не надо было городить, надо по исходному WSDL сгенерить код асинхронных вызовов чуть по-другому, чтобы в асинхронный вызов можно было сразу подать AsyncCallback или просто Callback. Тогда на любой из показанных либ или даже вручную это решается проще.

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

V>Такая же точно техника и точно так же типы целиком указывать надо.

V>В общем, эта задача решалась бы банально, если бы не надо было городить такие обертки-адаптеры под нормальный асинхронный паттерн. А чтобы их не надо было городить, надо по исходному WSDL сгенерить код асинхронных вызовов чуть по-другому, чтобы в асинхронный вызов можно было сразу подать AsyncCallback или просто Callback. Тогда на любой из показанных либ или даже вручную это решается проще.

Почему никто не видит самого простого варианта -- оставить синхронные методы. Для сложных ситуаций (цепочки вызовов) так проще и лучше. Забывают, что вызовы бывают не только простыми, но и сложными. Зачем еще что-то городить сверху для сложных ситуаций? KISS -- сделайте это проще, тупорылые.

Программист должен сам решить, в каком случае что использовать. В простейшем случае конечно удобнее асинхронный метод -- когда один вызов и одна подписка. Когда цепочка -- то только синхронные + обертка всех вызовов в асинхронный паттерн. Ну это же очевидно!

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

Здравствуйте, Аноним, Вы писали:

А>Программист должен сам решить, в каком случае что использовать. В простейшем случае конечно удобнее асинхронный метод -- когда один вызов и одна подписка. Когда цепочка -- то только синхронные + обертка всех вызовов в асинхронный паттерн. Ну это же очевидно!

Это потребует доп. поток. А если у нас много таких процессов паралельно? В общем, не все так просто особенно для мобильного софта, где такты пока считают.

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

Например для плюсов библиотечно как-то так:
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/example/http/server4/coroutine.hpp
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/example/http/server4/yield.hpp

Пример кода:
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/example/http/server4/server.cpp
(см в примере reenter, fork (!!!), yield)

Для C# тоже можно построить библиотечно на механизме IEnumerable/yield, разве что fork не получится.

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

V>Это потребует доп. поток. А если у нас много таких процессов паралельно? В общем, не все так просто особенно для мобильного софта, где такты пока считают.

Вы не поняли. Сделать возможность использовать синхронные и асинхронные методы -- по выбору.

Для простых случаев -- когда нужно только вызывать метод и получить результат -- использовать асинхронный вариант.

Когда же нужна последовательная сложная комбинация -- только синхронные методы. Чтобы не занимать UI-поток -- всю эту цепочку вызовов запускаем в BackgroundWorker.

Понятно теперь?

V>Твоя мысль насчет расписать асинхронный код как синхронный абсолютно правильная и вовсе не новая, но напрямую это не делается, это делается только на продолжениях или их эмуляциях разной степени подробностей, включая фиберы.

А в каком случае это нужно?

Зачем вообще нужны асинхронные вызовы в WP7? Только для одной цели: не занимать UI-поток. То есть чтобы пользователь вместо замершей формы видел какой-то индикатор прогресса. Тогда достаточно всего 1-го потока дополнительно к UI-потоку. Зачем этой херней усложнением заниматься?

V>Для C# тоже можно построить библиотечно на механизме IEnumerable/yield, разве что fork не получится.

Не в том направлении у вас работают мозги. Для таких случаев как этот -- асинхронные вызовы вообще не нужны (только один BackgroundWorker и все). Ну только геммор и сложность они добавляют и ничего больше.

А эти недоумки из MS таких вещей не понимают. Есть такая болезнь -- усложмизм называется. Когда чел только начал программировать -- хочет сделать все как можно круче -- с применением всех ему известных приемов. И в таком случае дуралей пихает их где можно и где не можна. Так вот именно это произошло с командой Silverlight. Ведь другого никакого логического объяснения нет -- студентов набрали, которые болеют усложмизмом (скорее всего из Индии). И эта их болезнь как раковая опухоль распространяется дальше -- ведь в самом ядре они повставляли палки тем, кто использует принцип KISS.

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

В новой верссии они в другую крайность перейдут. Как вот Metro -- переболели усложмизмом пользовательского интерфейса -- сделали без всего.

Здравствуйте, Аноним, Вы писали:

А>Когда же нужна последовательная сложная комбинация -- только синхронные методы. Чтобы не занимать UI-поток -- всю эту цепочку вызовов запускаем в BackgroundWorker.
А>Понятно теперь?

С самого начала было понятно и уже ответил. Это дороже в общем случае. К тому — же неэффективное использование ресурсов ОС.
Если алгоритм многошаговый, то потребуются дополнительные телодвижения по синхронизации шагов алгоритма. Уже многократно показано во всевозможных сценариях, что асинхронная модель и конечный автомат сверху нее (или продолжения) — самый дешевый и масштабируемый подход:

	Сравнение масштабируемости синхронного и асинхронного подхода в работе с сетью

V>>Твоя мысль насчет расписать асинхронный код как синхронный абсолютно правильная и вовсе не новая, но напрямую это не делается, это делается только на продолжениях или их эмуляциях разной степени подробностей, включая фиберы.

А>А в каком случае это нужно?

Чтобы перейти от описания работы автомата (что есть нетривиально) к "привычному" коду на любимом ЯП.


А>Зачем вообще нужны асинхронные вызовы в WP7? Только для одной цели: не занимать UI-поток. То есть чтобы пользователь вместо замершей формы видел какой-то индикатор прогресса. Тогда достаточно всего 1-го потока дополнительно к UI-потоку. Зачем этой херней усложнением заниматься?

Я уже сказал — тогда появится дополнительная задача общения таких потоков с основным. Тебе придется придумывать калбеки и нотификаторы, привязывать их к примитивам синхронизации и т.д. В конечном итоге ты напишешь точно такую же "асинхронность для бедных", только вручную. Кстате, взять тот же boost::asio, если низлежащая система не предоставляет асинхронных возможностей из коробки, то эта асинхронность эмулируется ручками. Со всеми вытекающими. Предлагаешь каждый раз делать вид, что низлежащая система ничем не может помочь? Можно поинтересоваться — какой смысл? Потому что Not invented here?

Т.е. если эту асинхроность напишешь сам, то тебе будет более понятно происходящее, что ле?
Ну напиши несколько раз, делов-то...


V>>Для C# тоже можно построить библиотечно на механизме IEnumerable/yield, разве что fork не получится.

А>Не в том направлении у вас работают мозги. Для таких случаев как этот -- асинхронные вызовы вообще не нужны (только один BackgroundWorker и все). Ну только геммор и сложность они добавляют и ничего больше.

Я не уверен, что приведена задача целиком. Это была выжимка из проблемы. В реальной задаче обычно еще нотификации, ожидания и нетривиальные реакции на результат предыдущих задач. Отличие показаной выжимки от реально-происходящего такое, что в приведенной задаче результат всех предикатов был известен заранее, до вызова первого шага асинхронной операции. А в реальности требуется ветвление по чуть более актуальным признакам.


А>А эти недоумки из MS таких вещей не понимают. Есть такая болезнь -- усложмизм называется. Когда чел только начал программировать -- хочет сделать все как можно круче -- с применением всех ему известных приемов. И в таком случае дуралей пихает их где можно и где не можна. Так вот именно это произошло с командой Silverlight. Ведь другого никакого логического объяснения нет -- студентов набрали, которые болеют усложмизмом (скорее всего из Индии). И эта их болезнь как раковая опухоль распространяется дальше -- ведь в самом ядре они повставляли палки тем, кто использует принцип KISS.

Остапа понесло... Я же говорю — распиши сам ручками несколько вариантов, и ты увидишь, что даже эмулируя асинхронность по предложенному тобой варианту, ты придешь к такому же паттерну асинхронности: { функция, контекст, сигнал_завершения }. И единственный вопрос, на который останется ответить — а нахрена было ручками-то?


А>В новой верссии они в другую крайность перейдут. Как вот Metro -- переболели усложмизмом пользовательского интерфейса -- сделали без всего.

Разве? Поменялось только главное меню оболочки и окантовка окон. ИМХО только для того, чтобы не было столь радикального различия на мобильных платформах с ограниченным разрешением и десктопных. Т.е. они решили сэкономить и не плодить клоны собственных ОС, похоже... Но взять их флагманские продукты: на них риббон, т.е. развитие КЛАССИЧЕСКОГО GUI-меню приложений, и этот риббон никуда не делся и не собирается, а вовсе наоборот — им окучили оставшиеся утилиты, что не окучили при выпуске Win7. Похоже он переживет Metro, которому осталось жить не так долго, согласно прогнозам на развитие разрешающей способности экранов, порядка 7-8 лет. Вернее, само Метро никуда не денется, бо это просто АПИ, но мода на "просто квадратики" в основной теме оформления ес-но пройдет.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Andrey-D, Вы писали:

AD>>2. Решение на клиенте в лоб (лучше написать или сгенерировать обертку под каждый метод):

А>Это было первой мыслью. Но, к сожалению, не работает -- зависает. Вызов FunCompleted вызывается в UI-потоке, а он заблокирован _resetEvent.WaitOne().

Есть рабочее решение для SL связанное с использованием ManualResetEvent.
Для вас все еще актуально?

Здравствуйте, Аноним, Вы писали:

А>Есть рабочее решение для SL связанное с использованием ManualResetEvent.
А>Для вас все еще актуально?

Для WP7? Актуально конечно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Есть рабочее решение для SL связанное с использованием ManualResetEvent.
А>>Для вас все еще актуально?

А>Для WP7? Актуально конечно.
Для WP7 не пробовал, поэтому ничего не обещаю, но там должен быть точно такой же SL с одним UI-потоком.

Но, в SL та же проблема с цепочками асинхронных вызовов и зависанием главного потока при попытке сделать EventWaitHandle.WaitOne().
Это происходит потому, что мы вызовом WaitOne заставляем ждать главный поток события завершения другого потока, а продолжиться после установки Set он уже не может. Происходит deadlock. На форумах (в том числе англоязычных) рекомендуют не использовать Manual/AutoResetEvent'ы и менять образ мышления на асинхронный. Но разработчики все равно часто задают вопросы о том как избавиться от async лапши в коде.

Проблема с зависанием EventWaitHandle.WaitOne() решается тем, что мы делаем его не в UI-потоке, а в фоновом потоке (с помощью ThreadPool.QueueUserWorkItem, например).
При этом мы не уходим от асинхронности, т.к. нам нужно подписаться на событие завершения кода в фоновом потоке, но при этом вынесенный код можно синхронизировать с помощью сигналов (EventWaitHandle) и имитировать синхронность.

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

V>С самого начала было понятно и уже ответил. Это дороже в общем случае. К тому — же неэффективное использование ресурсов ОС.

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

Каким образом внесение асинхронных вызовов что-ибо сделает дешевле? Даже если бы был многоядерный процессор -- то не помогло бы, т.к. вызовы последовательные.

V>Чтобы перейти от описания работы автомата (что есть нетривиально) к "привычному" коду на любимом ЯП.

В каком случае вообще нужны асинхронные методы? Только для тривиальных случаев -- подписался на событие и вызвал. Когда комбинация -- то только синхронные методы + обертка в BackgroundWorker.


V>Я уже сказал — тогда появится дополнительная задача общения таких потоков с основным.

А вы BackgroundWorker использовали не? Там это очень просто реализуется.

V> Тебе придется придумывать калбеки и нотификаторы, привязывать их к примитивам синхронизации и т.д.

Бред молодой человек. Курите BackgroundWorker.

Здравствуйте, Аноним, Вы писали:

А>Каким образом внесение асинхронных вызовов что-ибо сделает дешевле? Даже если бы был многоядерный процессор -- то не помогло бы, т.к. вызовы последовательные.
А>В каком случае вообще нужны асинхронные методы? Только для тривиальных случаев -- подписался на событие и вызвал. Когда комбинация -- то только синхронные методы + обертка в BackgroundWorker.
Если последовательные операции занимаются вводом/выводом, то асинхронность позволит вообще не занимать поток, пока не завершится очередная операция ввода/вывода. Следовательно, при необходимости этот поток может заниматься другой полезной работой.

Здравствуйте, Аноним, Вы писали:

Нашел объяснение. В WP7 вызов вебсервисоа осуществляеться в UI потоке, поэтому когда тормозим поток не срабатывает "Completed"
Решаеться запуском в отдельном потоке:
Рабочий пример можно забрать тут (если я правильно понял, что нужно сделать)
Использовал SimpleMvvmToolkit.

Код из MainPageViewModel.cs

        private void GetData()
        {
            ThreadPool.QueueUserWorkItem(DoWork);
        }

        #endregion Commands

        private void DoWork(object state)
        {
            WebService1SoapClient service = new WebService1SoapClient();
            AutoResetEvent reset = new AutoResetEvent(false);

            //Clear\]
            FunResult = 0;
            ActionResult1 = "wait..";
            ActionResult2 = "wait..";
            ActionResult3 = "wait..";
            Completed = "Not completed";
            service.FunCompleted += (s, args) =>
            {
                FunResult = args.Result;
                reset.Set();
            };
            service.FunAsync();
            reset.WaitOne();

            if (0 == FunResult % 2)
            {
                service.Action1Completed += (s, args) =>
                {
                    ActionResult1 = args.Result;
                    reset.Set();
                };
                service.Action1Async();
                reset.WaitOne();
            }

            if (0 == FunResult % 3)
            {
                service.Action2Completed += (s, args) =>
                {
                    ActionResult2 = args.Result;
                    reset.Set();
                };
                service.Action2Async();
                reset.WaitOne();
            }

            if (0 == FunResult % 4)
            {
                service.Action3Completed += (s, args) =>
                {
                    ActionResult3 = args.Result;
                    reset.Set();
                };

                service.Action3Async();
                reset.WaitOne();
            }

            Completed = "Completed : " + DateTime.Now;
        }

А>Здравствуйте, Andrey-D, Вы писали:

AD>>А как ты проверяешь?
AD>>На тесте консолька+веб сервис вызов FunCompleted идет в отдельнои потоке.

А>На эмуляторе Windows Phone7. Там почему то так.

Здравствуйте, Аноним, Вы писали:

На всякий случай пример здесь

Автор: Andrey-D
Дата: 13.04.12

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Есть рабочее решение для SL связанное с использованием ManualResetEvent.
А>>>Для вас все еще актуально?

А>>Для WP7? Актуально конечно.
А>Для WP7 не пробовал, поэтому ничего не обещаю, но там должен быть точно такой же SL с одним UI-потоком.

А>Но, в SL та же проблема с цепочками асинхронных вызовов и зависанием главного потока при попытке сделать EventWaitHandle.WaitOne().
А>Это происходит потому, что мы вызовом WaitOne заставляем ждать главный поток события завершения другого потока, а продолжиться после установки Set он уже не может. Происходит deadlock. На форумах (в том числе англоязычных) рекомендуют не использовать Manual/AutoResetEvent'ы и менять образ мышления на асинхронный. Но разработчики все равно часто задают вопросы о том как избавиться от async лапши в коде.

А>Проблема с зависанием EventWaitHandle.WaitOne() решается тем, что мы делаем его не в UI-потоке, а в фоновом потоке (с помощью ThreadPool.QueueUserWorkItem, например).
А>При этом мы не уходим от асинхронности, т.к. нам нужно подписаться на событие завершения кода в фоновом потоке, но при этом вынесенный код можно синхронизировать с помощью сигналов (EventWaitHandle) и имитировать синхронность.

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

А>>В новой верссии они в другую крайность перейдут. Как вот Metro -- переболели усложмизмом пользовательского интерфейса -- сделали без всего.

V>Разве? Поменялось только главное меню оболочки и окантовка окон. ИМХО только для того, чтобы не было столь радикального различия на мобильных платформах с ограниченным разрешением и десктопных. Т.е. они решили сэкономить и не плодить клоны собственных ОС, похоже... Но взять их флагманские продукты: на них риббон, т.е. развитие КЛАССИЧЕСКОГО GUI-меню приложений, и этот риббон никуда не делся и не собирается, а вовсе наоборот — им окучили оставшиеся утилиты, что не окучили при выпуске Win7. Похоже он переживет Metro, которому осталось жить не так долго, согласно прогнозам на развитие разрешающей способности экранов, порядка 7-8 лет. Вернее, само Метро никуда не денется, бо это просто АПИ, но мода на "просто квадратики" в основной теме оформления ес-но пройдет.

Основное отличие метро интерфейса — отсутствие overlapped windows. Того на чем последние 20 лет строился UI. Многим по началу рвет башню. Хочется делать окошки, многоуровневые менюшки, mdi итп

Что касается время жизни metro то совершенно непонятно причем тут разрешение. Ведь в первую очередь все квадратики адаптированы под тач и какое бы разрешение не было размеры планшетов и пальцев мало изменятся.