Le thread de l'interface principale principale gérée reste-t-il sur le même thread (non géré) du système d'exploitation?

Question

Je crée une interface utilisateur WPF UI managée vers une application Win32 héritée. L'interface frontale WPF est l'exécutable. Dans le cadre de ses routines de démarrage, je démarre l'application héritée en tant que DLL dans un deuxième thread. Toute opération d'interface utilisateur (y compris CreateWindowsEx, etc.) par l'application héritée est appelée de nouveau sur le thread d'interface utilisateur principal.

Dans le cadre du processus d'arrêt de l'application, je veux nettoyer correctement. Entre autres choses, je veux appeler DestroyWindow sur toutes les fenêtres non gérées, afin qu'ils puissent se nettoyer correctement. Ainsi, pendant l'arrêt j'utilise EnumWindows pour essayer de trouver toutes mes fenêtres non managées. Puis j'appelle DestroyWindow une liste que je génère. Ceux-ci fonctionnent sur le thread UI principal.

Après cette connaissance de base, à ma question réelle:
Dans la procédure d'énumération des EnumWindows, je dois vérifier si l'une des fenêtres de haut niveau de retour est l'une de mes fenêtres non gérés. Je fais cela en appelant GetWindowThreadProcessId pour obtenir l'id de processus et l'ID de thread du créateur de la fenêtre. Je peux comparer l'identifiant de processus avec Process.GetCurrentProcess().Id pour vérifier si mon application l'a créé.

Pour plus de sécurité, je veux aussi voir si mon thread UI principal a créé la fenêtre. Toutefois, l'ID de thread renvoyé est ThreadId du système d'exploitation (qui est différent de l'ID de thread géré). Comme expliqué dans this question, le CLR se réserve le droit de reporter le thread géré à différents threads du système d'exploitation. Puis-je compter sur le CLR pour être "assez intelligent" pour ne jamais le faire pour le thread principal de l'interface utilisateur (en raison de l'affinité des threads de l'interface utilisateur)? Ensuite, je pourrais appeler GetCurrentThreadId pour obtenir l'ID de thread non géré du thread UI principal pour la comparaison.

Answer 1

La possibilité de mapper un thread géré à un schéma de thread personnalisé a été introduite dans .NET 2.0 pour les hôtes CLR personnalisés. Plus précisément, SQL Server. Ils voulaient utiliser des fibres, une fonctionnalité native de SQL Server. Ils n'ont pas pu le faire, le projet a été abandonné. À ma connaissance, il n'y a pas d'hôtes CLR qui profitent réellement de cette fonctionnalité.

Il ne sera jamais un problème dans l'hôte CLR par défaut, celui que vous obtenez dans une application WPF. Un thread géré est toujours mappé à un thread du système d'exploitation et le fait de manière cohérente. Vous pouvez compter sur la valeur renvoyée par GetCurrentThreadId(). Je doute sérieusement que cela changera jamais, ce serait un changement majeur. Il est peu probable que cela soit vrai pour un hôte futur, similaire à Silverlight, mais votre code ne s'en approchera jamais.