2010-07-15 5 views
1

J'ai une application qui traite les transferts de fichiers. Dans certains cas, j'ai besoin de lancer des exécutables de pré/post-traitement qui font des choses avec les fichiers.Lancer le processus à partir du thread de travail Threadpool (et attendre si nécessaire)

Ainsi, l'ordre des événements (en bref) serait comme ceci:

fil
  1. de travail est créé
  2. travailleur se rend compte qu'il a besoin de lancer un exécutable pré-traitement avant de commencer le transfert prétraiter est lancé, le travailleur attend ... s'il attend trop longtemps, le transfert ne se produira pas et le thread devrait terminer gracieusement
  3. Le fichier est transféré
  4. Le travailleur se rend compte qu'il doit lancer un exécutable de post-traitement après le transfert est finishe d
  5. post-processus est lancé, un travailleur ne se soucie pas d'attendre

Fondamentalement, je ne me soucie pas combien de temps le processus post-exécutable court après le transfert a eu lieu. Par conséquent, devrais-je anticiper des problèmes si je lance le processus à partir d'un thread qui est ensuite retourné à la piscine?


// processus post

 Process process = null; 
     ProcessStartInfo psi = new ProcessStartInfo(executable, args); 
     psi.UseShellExecute = true; 

     try 
     { 
      process = Process.Start(psi); 
      //The pre-process simply calls Process.WaitForExit(timeout value) 
      launched = true; 
     } 
     catch (InvalidOperationException) { } 
     catch (ArgumentException) { } 
     catch (System.ComponentModel.Win32Exception) { } 
     catch (System.IO.FileNotFoundException) { } 

Répondre

4

Il n'y a rien de mal à cela du tout.

Think about it:

  • De retour d'un fil à la threadpool ne signifie pas que quoi que ce soit - le fil est toujours là.
  • Les processus ne dépendent en aucune façon de leurs threads ou processus parents - il est possible qu'un processus génère un processus enfant puis quitte.
+0

Je voudrais ajouter à cette réponse la recommandation d'utiliser 'Task' objets (si vous êtes sur .NET 4.0). Ils propagent proprement des exceptions et soutiennent un modèle d'annulation unifié. –

1

C'est très dangereux. Si vous utilisez tous vos threads de pool de threads sur des tâches de longue durée, alors d'autres choses qui en ont besoin cesseront de fonctionner. Vous pouvez même verrouiller votre application entière.

La règle est simple:

  • court et rapide: Discussion Piscine Discussion
  • long et lent: fil créé manuellement
+0

"très dangereux" - Je pense que vous êtes un peu trop conservateur. Le pool de threads .NET a une [limite par défaut de 250 threads] (http://msdn.microsoft.com/en-us/library/0ka9477y.aspx), que vous pouvez agrandir si nécessaire. Consommer l'un de ces threads pour attendre un processus est peu susceptible de causer des dommages. –

+1

Incorrect. Il n'attend pas que le processus se termine. – SLaks

+1

J'ai utilisé toute la bande de roulement avant. Bien sûr, il était de retour lorsque le défaut était de seulement 100, mais cela peut arriver à des moments surprenants. –

Questions connexes