Pourquoi un appel au code non géré à partir d'un thread .NET BackgroundWorker affecte-t-il l'interface utilisateur?

Question

J'ai une longue série d'opérations dans un thread BackgroundWorker .NET 2.0. Lorsque j'appelle un code non géré situé dans un assembly référencé, l'interface utilisateur est gelée jusqu'à la fin de l'appel.

Pourquoi est-ce? Ne devrais-je pas passer ces appels à partir du thread BackgroundWorker ?

Oui, il s’agit d’un composant COM, mais je ne sais pas comment dire s’il s’agit ou non de STA et quelles en sont les implications / la résolution. Je passe plusieurs appels à ce composant, mais ce ne sont que les appels de longue date où je remarque que l'interface utilisateur ne répond plus.

Ces appels récupèrent les données d'un serveur.

Answer 1

Vous avez la balise COM dans la question - appelez-vous dans un composant COM? Est-ce un composant STA? Si tel est le cas, il se pourrait bien que son travail sur le fil de l'interface utilisateur soit rétabli. J'admets volontiers que je suis loin d'être un expert en matière de communication, mais je ne serais pas surpris que ce soit le problème.

Que se passe-t-il si vous passez les appels à partir d'un nouveau thread que vous avez explicitement créé?

Answer 2

Oui, cela se produit-il avec tout le code non managé ou juste un composant ou une API spécifique? Si tel est le cas, que fait ce code non managé?

Answer 3

De plus, vous pouvez simplement commenter votre code actuel dans BackgroundWorker (vous exécutez RunWorkerAsync correctement ...) et y mettre un sommeil réparateur. Si votre interface graphique ne répond plus, quelque chose ne va pas, sinon c'est le code que vous appelez, comme le souligne Jon, ce pourrait être le cas avec COM.