2010-09-10 9 views
4

J'ai un thread d'arrière-plan que j'utilise pour le traitement séparément de l'interface graphique, et tout fonctionne correctement entre les threads. Cependant quand je ferme l'application, le programme "se ferme" mais ne tue pas le processus. Le thread d'arrière-plan maintient le programme en vie, semble-t-il.C# isBackground Le thread ne se termine pas correctement

J'ai défini "myThreadInstance.IsBackground = true;", et je pensais que cela nécessiterait C# pour le tuer quand il est tué.

Je suis en train de tester tout cela dans Visual Studio (2010, en utilisant .NET 4.0), et après la première génération, tout le reste échoue parce que l'exe est toujours utilisé, donc il ne peut pas l'écraser. En regardant dans le gestionnaire de tâches, il est là. Tuer Visual Studio libère le processus vbhost qui libère mon exe. Tuer le processus de mon exe, fait réapparaître vbhost dans une seconde ou deux.

+0

Utilisez-vous l'arrière-plan pour cela? – Kangkan

+0

Gardez à l'esprit que les threads d'arrière-plan sont interrompus via 'Thread.Abort', ce qui peut être bloqué avec des droits suffisants. Je ne sais pas non plus avec quelle rapidité le thread s'interrompt si le code non géré est exécuté. Est-ce que l'un ou l'autre est possible? –

Répondre

0

Essayez d'utiliser Application.Exit (0); dans l'événement form_closing/form_closed.

Bogue: Je pense que cela pourrait être un bug. Regardez les commentaires au bas de cette page MSDN: http://msdn.microsoft.com/en-us/library/system.threading.thread.isbackground.aspx

Également, essayez d'utiliser le BackgroundWorker. Voici une bonne description dans le VisualStudio Magazine: http://visualstudiomagazine.com/articles/2007/09/01/simplify-background-threads.aspx

+0

J'ai essayé d'utiliser un BackgroundWorker, et la même chose arrive. C'est alors que je l'ai changé pour Threads qui a bien fonctionné pour moi avant dans une autre application. Je ne suis pas sûr de la différence, et pourquoi cela bloquerait le processus ... – Nick

+0

Je ne peux pas être sûr de voir ce qui se passe dans le code mais une chose est claire: nous ne pouvons pas compter sur le framework pour tuer le fond thread (comme il se doit faire.) Donc, pour résoudre ce problème, vous devrez peut-être recourir à un hack ou quelque chose. Essayez de déclencher un abandon sur le fil d'arrière-plan lorsque vous souhaitez fermer l'application. Est également Application.Exit (0); ne fonctionne pas? –

+0

De quel commentaire parlez-vous sur la page MSDN? Il n'y a pas de commentaires du tout. Quel bug veux-tu dire? J'ai le même problème maintenant dans ma demande. Lorsqu'une exception non gérée mais continuable est levée, aucun thread d'arrière-plan n'est tué, ils continuent tous à s'exécuter. Je ne peux tout simplement pas les arrêter tous lorsque la fenêtre principale est fermée. Et il n'y a plus de fils de premier plan. (J'ai vérifié dans la fenêtre des threads.) – ygoe

0

Ce type de problème nécessite généralement du code pour comprendre. Prenez votre application et coupez-la au strict minimum nécessaire pour montrer le problème. Cependant, il est fort probable que vous ne signifiez pas que le thread se termine ou que le thread est une bête de si longue durée qu'il ne voit jamais le signal.

+0

Mais c'est le but de isBackground étant vrai. Vous ne devriez rien faire, .NET devrait automatiquement le tuer. – Nick

+0

Comme Sidharth dit ci-dessous, vous ne pouvez pas compter sur le cadre pour nettoyer après vous. La seule façon d'être vraiment sûr est de le faire vous-même. Peu importe, si le fil ne répond pas au signal, alors il continuera ... – NotMe

1

En fait, en fonction de votre description et d'autres choses que vous avez essayé (et leurs résultats), je crois que la cause la plus probable est celle-ci:

Vous avez un autre avant-plan thread dans votre application, autre que celui que vous examinez.