fil Accrocher sortie

Question

est-il un moyen pour moi de brancher la sortie de fils gérés (c.-à exécuter un code sur un fil, juste avant sa sortie?)

J'ai développé un mécanisme d'accrochage sortie de fil qui fonctionne pour certains threads. Étape 1: développez une classe STA COM 'hook' qui prend une fonction de rappel et l'appelle dans son destructeur. Étape 2: créez une instance ThreadStatic de cet objet sur le thread que je veux raccorder et transmettez l'objet à un délégué géré converti en un pointeur de fonction non géré. Le délégué est ensuite appelé à la sortie du thread (puisque le CLR appelle IUnknown :: Release sur tous les connecteurs RCW STA COM dans le cadre de la sortie du thread).

Ce mécanisme fonctionne sur, par exemple, les threads de travail que je crée dans le code à l'aide de la classe Thread. Toutefois, cela ne semble pas fonctionner pour le thread principal de l'application (qu'il s'agisse d'une application console ou Windows). L'objet COM 'hook' semble être supprimé trop tard dans le processus d'arrêt et la tentative d'appel du délégué échoue.

(La raison pour laquelle je souhaite implémenter cette fonctionnalité est que je peux exécuter du code COM natif sur le thread sortant qui fonctionne avec les objets COM STA créés sur le thread avant qu'il ne soit trop tard (avant le thread a quitté, et il n'est plus possible de travailler avec des objets STA COM sur ce thread.))

Answer 1

Contrôlez-vous la création de threads? Il est probablement plus simple d'envelopper simplement le code du thread dans une clause try ... finally, et de mettre votre code dans le fichier final.

Notez que lorsque l'AppDomain s'arrête, vous ne pouvez jamais être sûr que votre code sera appelé car l'arrêt peut être moins que gracieux. Quand vous dites "Destructeur", je suppose que vous voulez dire un destructeur C++/CLI - c'est-à-dire la méthode .Dispose()? Si vous devez prendre en charge l'accrochage avant la fin du processus, vous pouvez essayer l'événement AppDomain.CurrentDomain.ProcessExit - qui ne semble pas provenir d'une exception non gérée ou AppDomain.CurrentDomain.UnhandledException qui ne semble déclencher qu'une exception non gérée.

Rien de tout cela ne semble particulièrement robuste, pensez-y ...