Асинхронное ожидание синхронной путаницы - ужас
Я, БУДУЧИ СВЕДЕННЫМ С УМА ОТ ЭТОГО :(
Поэтому я пытаюсь написать приложение для метро. Оставляя в стороне утомительный факт, что половина рамок была вырвана, есть одна вещь, которую я просто не могу исправить.
Я хочу получить все файлы в папке (на самом деле рекурсивно, но этот бит не имеет значения), и я хочу сделать это синхронно. Я верю
StorageFolder это класс для этого, так как он представляет собой папку.Теперь, если бы у него был
GetFiles() методу я был бы рад, но вместо этого его получил GetFilesAsync() Все, что я хочу сделать, это вызвать этот метод синхронно.Теперь, если я вызываю это, оно просто немедленно возвращается, что, как я понимаю, является природой асинхронных вызовов, когда они блокируются. Так что я мог бы дождаться его окончания:
IReadOnlyList<StorageFile> f = await requestedFolder.GetFilesAsync();Но это означало бы необходимость пометить вызывающий метод как асинхронный и просто распространить боль на метод над ним. И так далее, чтобы дождаться завершения метода, вам нужно "ждать", но это означает, что вызывающий абонент асинхронен и т. д. и т. д., Пока все приложение не превратится в один массивный асинхронный суп.
С учетом асинхронности, методы возвращают
Taskс, я пробовал Wait()ing на этом, но это просто вызывает немедленный тупик (на одном потоке, из того, что я могу сказать - приятно).Есть идеи? Никаких умных ответов о том, что Google - Мой друг, - это не так. Я умолял его в течение последних 5 часов получить ответ.
Sergey Alexandrovich Kryukov
I never tried it (and don't really want to), but I have bad impression about Metro. I looked for API and found the lack of synchronous methods in Storage. And, long time ago, I got an opinion that asynchronous methods are just lame. They flourished (to certain extent) when multithreading was not a commonplace, so many developers were afraid of creating threads. In fact, multithreading on the level of application is way more straightforward than asynchronous API. Of course, you often need thread synchronization primitives, but when one learns them, their usage becomes universal, agnostic to the application, while all asynchronous APIs are application-specific. Also, with threads you have more control, and the logic is more linear. Maybe I miss something, but I really fail to see a reason for such API, and the lack of the synchronous API (with blocking calls, of cause) does not seem any reasonable to me.
Поскольку я разделяю ваши опасения, я проголосовал 5 за этот вопрос. Извините, что я не могу вам сейчас помочь; все, что я мог бы посоветовать, - это избегать метро. Мне действительно не нужно никакого понимания того, кому это может понадобиться и почему... Существует большое количество некоторых технологий Microsoft, которые никуда не пошли, только загрязнили тяжелую унаследованную нагрузку дистрибутивов ОС; кто знает, может быть, Metro-одна из таких вещей... Я бы предпочел подождать Мидори, все еще надеясь, что они в конечном итоге завершат эту ОС, единственный разумный путь, который я вижу...
--СА