У WinRT все еще есть те же старые ограничения на потоковое UI?

В WinForms почти весь ваш пользовательский интерфейс зависит от потока. Вы должны использовать [STAThread], чтобы общие диалоги работали, и вы не можете (безопасно) получить доступ к элементу пользовательского интерфейса из любого потока, отличного от того, который его создал. Из того, что я слышал, из-за того, что именно то, как работают Windows, - дескрипторы окон зависят от потока.

В WPF эти же ограничения были сохранены, потому что в конечном итоге он все еще строился поверх одного и того же Windows API, все еще обрабатывает окна (хотя в основном только для окон верхнего уровня) и т.д. На самом деле WPF даже сделал вещи более ограничительными, потому что вы даже не можете получить доступ к таким вещам, как растровые изображения по потокам.

Теперь наступает WinRT, совершенно новый способ доступа к Windows - новый, чистый сланец. Мы все еще придерживаемся тех же самых старых ограничений на потоки (в частности: только возможность манипулировать элементом управления пользовательского интерфейса из потока, который его создал), или они открыли это?

ОТВЕТЫ

Ответ 1

Я бы ожидал, что это будет одна и та же модель, но гораздо проще в использовании, по крайней мере, с С# и VB, с новой обработкой async, которая позволяет писать синхронный метод, который просто использует "ожидание", когда ему нужно дождитесь завершения долговременной задачи перед продолжением.

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

Ответ 2

Модель резьбы идентична. По-прежнему существует понятие однопоточных и многопоточных квартир (STA/MTA), оно должно быть инициализировано вызовом RoInitialize. Которая ведет себя очень похоже на CoInitialize в именах, аргументах и ​​ошибках. Поток пользовательского интерфейса однопоточный, подтвержденный в 36:00 в этом видео.

Ответ 3

Модель HTML/CSS UI по своей сути является однопоточной (до появления веб-работников в последнее время JS не поддерживает потоки). Xaml также является однопоточным (потому что разработчикам очень сложно писать код в многопоточный графический интерфейс).

Ответ 4

У базовой модели потоковой передачи есть некоторые ключевые отличия. Когда приложение запускается, создается ASTA (приложение STA) для запуска вашего пользовательского интерфейса, как я показал в разговоре. Эта ASTA не разрешает повторное подключение - вы не будете получать несвязанные звонки при совершении исходящего звонка. Это существенное отличие от ГНА.

Вам разрешено создавать async workitems - см. пространство имен Windows.System.Threadpool. Эти потоки workitem автоматически инициализируются в MTA. Как отметил Ларри, веб-работники - это эквивалентная концепция JS.

Ваши компоненты пользовательского интерфейса связаны с потоком. См. класс Windows.UI.Core.CoreDispatcher для получения информации о том, как выполнять код в потоке пользовательского интерфейса. Вы можете проверить образец потока для некоторого примера кода для обновления пользовательского интерфейса из асинхронной операции.

Ответ 5

Все происходит по-разному.

Хотя верно, что базовая модель потоков одна и та же, ваш вопрос, как правило, связан с тем, как логический concurrency работает с пользовательским интерфейсом, а в отношении того, что разработчики видят в Windows 8, будет новым.

Как вы упомянули большинство ранее заблокированных диалогов. Для приложений Metro многие компоненты пользовательского интерфейса не блокируют все. Помните, что разговор о WinRT был асинхронным? Это также относится к компонентам пользовательского интерфейса.

Например, этот код .NET 4 не обязательно будет убивать ваш жесткий диск, потому что блокировка пользовательского интерфейса на Show (пример С#):

bool formatHardDrive = true;
if (MessageBox.Show("Format your harddrive?") == NO)
    formatHardDrive = false;
if (formatHardDrive == true)
    Format();

В Windows 8 Metro многие компоненты пользовательского интерфейса, такие как Windows.UI.Popups.MessageDialog, по умолчанию асинхронны, поэтому вызов Show немедленно (логически) попадает в следующую строку кода перед пользователем вход извлекается.

Конечно, это элегантное решение, основанное на шаблонах дизайна ожидания/обещания (пример Javascript):

var md = Windows.UI.Popups.MessageDialog("Hello World!");
md.showAsync().then(function (command) { 
    console.log("pressed: " + command.label); });

Дело в том, что, хотя модель потоковой передачи не изменяется, когда большинство людей упоминает интерфейс и потоки, они думают о логическом concurrency и о том, как он влияет на модель программирования.

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