Комментарии 17
Жаль, что нацелено на 3.5. Получается никакого async. :-(
Согласен. Было бы неплохо, если бы добавили асинхронку хотя бы в старом варианте, по типу BeginInvoke — EndInvoke.
P.S. Потенциал неплохой, я бы посоветовал портировать на WP8 и Xamarin, думаю, что будет популярно в Xamarin Store ;)
P.S. Потенциал неплохой, я бы посоветовал портировать на WP8 и Xamarin, думаю, что будет популярно в Xamarin Store ;)
Самое забавное, что async отлично можно завести и на .NET 2.0, достаточно нужные классы из Mono вытащить и скомпилировать в dll-ку. У меня где-то ещё валялась версия такой библиотеки и для .NET 4, работающая без KB, требуемого решением от мелкомягких.
А это востребовано? Могу попробовать отделить API из своего VK unO
apps.microsoft.com/windows/uk-ua/app/vk-uno/87dc7d15-1241-4e75-b7c9-a0aa802714d6
apps.microsoft.com/windows/uk-ua/app/vk-uno/87dc7d15-1241-4e75-b7c9-a0aa802714d6
А в чем проблема использовать Task.StartNew(() => {...}).ContinueWith(t => {...})?
Можно свой или сторонний TaskHelper какой-то взять на вооружение. Через тот-же хелпер можно прикрутить стандартное логгирование ошибок.
Можно свой или сторонний TaskHelper какой-то взять на вооружение. Через тот-же хелпер можно прикрутить стандартное логгирование ошибок.
Наверное, в том, что HTTP запросы IO-Bound и Task.StartNew будет кушать ресурсы без необходимости. SO.
Насколько я понял, в комментарии, на который я ответил, автор раздосадован, что не сможет задекорировать свой метод аттрибутами 'async — await'. Если я прав, то Ваш пример о том же, о чем я написал, а именно обойтись без сахара async-await и использовать TPL.
Насколько я понял, преимущество Вашего примера в том, что не занимается поток из Tread Pool. Я правильно понял?
Насколько я понял, преимущество Вашего примера в том, что не занимается поток из Tread Pool. Я правильно понял?
Да, но не совсем.
Независимо от того, как реализован метод в библиотеке (с async или без) его результат можно await'ить в своем методе, если он возвращает Task.
Мой пример о том, что если метод в библиотеке реализует IAsyncResult паттерн, то эффективнее будет использовать Task.FromAsync, чем оборачивать синхронный метод в Task.StartNew.
А проблема в библиотеке в том, что, она не реализует ассинхронное API ни каким образом. Т.е. придется использовать Task.StartNew, что в свою очередь будет не так эффективно.
Надеюсь так понятнее.
Независимо от того, как реализован метод в библиотеке (с async или без) его результат можно await'ить в своем методе, если он возвращает Task.
Мой пример о том, что если метод в библиотеке реализует IAsyncResult паттерн, то эффективнее будет использовать Task.FromAsync, чем оборачивать синхронный метод в Task.StartNew.
А проблема в библиотеке в том, что, она не реализует ассинхронное API ни каким образом. Т.е. придется использовать Task.StartNew, что в свою очередь будет не так эффективно.
Надеюсь так понятнее.
Да. Понятно.
Получается, если в Tread Pool имеется ограничение в 30 потоков, то невозможно будет даже при монопольном захвате пулла запустить больше 30 параллельных запросов IO/Web.
Получается, если в Tread Pool имеется ограничение в 30 потоков, то невозможно будет даже при монопольном захвате пулла запустить больше 30 параллельных запросов IO/Web.
Вроде ограничение в 64 потока: http://msdn.microsoft.com/en-us/library/dd383719(v=vs.110).aspx
А почему без async и только .NET 3.5? По-моему мало актуально. Я для Meridian (https://github.com/Stealth2012/meridian) использую самописную Portable-библиотеку, которая поддерживает async и может использоваться в проектах NET4.5/WP8/Win8.
О, спасибо! Как раз недавно задумал приложение по ВК, поискал библиотеку и не нашёл, пришлось писать самостоятельные велосипеды:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ВКонтакте API для .Net