J'ai un problème avec une certaine emballage de processus, et cela ne se produit que dans Windows XP. Ce code fonctionne parfaitement dans Windows 7. Je suis vraiment excité sur la raison pour laquelle les flux sont vides dans XP. J'ai également essayé d'utiliser la version String [] de processus.exec () et elle n'a fait aucune différence.
J'utilise la classe suivante à lire à partir du processus 'stdout et stardr (une instance pour chaque flux): < / p> et je l'utilise ici: Quelqu'un a des idées? Merci! EDIT: Synchronisation ajoutée Edit: Tout comme une mise à jour, les lecteurs de flux parent sont bloqués sur leur opération de lecture. Si je tue les processus de l'enfant, avec le gestionnaire de tâches, ils ont lu dans la nulle de la fermeture du flux.
4 Réponses :
Vous devez utiliser une structure de données sécurisée de fil; Je ne pense pas que la liste liée est le fil sûr.
J'ai mis à jour le code pour synchroniser. Il a toujours le même problème. : \
Une erreur qui me frappe est que LinkedList n'est pas synchronisé , mais vous essayez d'y écrire dans 2 threads.
Une autre chose à garder à l'esprit est Process.GetInputStream () renvoie le flux STDOUT du processus, vous devez donc renommer la variable actuellement appelée stdin < / code> à stdout pour empêcher la confusion.
Ouais, je me suis confus par l'utilisation de "stdin". Du point de vue de votre programme Java, c'est un flux d'entrée, mais du point de vue du processus, c'est stdout.
J'ai changé Stdin à Stdout avec l'ajout de la synchronisation.
Il y a des bugs connus dans les systèmes d'exploitation de Pre-Vista Windows où les dll de chargement peuvent provoquer une suspension dans IO.
E.g. Voir HTTP : //weblogs.java.net/blog/kohsuke/archive/2009/09/28/reading-stdin-may-cause-votre-jvm-hang et https://connect.microsoft.com/visualstudio/feedback/details/94701/94701/94701/9loadLibrary -Deadlocks-with-a-pipe-lisez
Je ne sais pas si c'est ce que vous courez, mais cela peut être lié.
En outre, je me souviens vaguement des problèmes pour obtenir un STDIN et STDOUT valides à partir d'applications Windows non console. Si votre appel à "Test.jar" utilise "Javaw" plutôt que "Java", cela pourrait aussi être la cause de votre problème aussi.
Oh, je viens d'utiliser Test.jar comme exemple. C'est bon à savoir, cependant.
Système de lecture.in est souvent un problème. Plus de liens vers Sun-UG rapporte dans ma réponse de cette question: Stackoverflow.com/questions/3836780/...
Comme certaines plates-formes natales ne fournissent que la taille de la mémoire tampon limitée pour les flux d'entrée et de sortie standard, une défaillance de l'écriture rapide du flux d'entrée ou de lire le flux de sortie de la sous-processus peut entraîner une blocage du sous-processus et même une impasse.
+1 Pour avoir une bonne question détaillée montrant que vous avez pensé à travers les problèmes potentiels pouvant survenir ici.
Après avoir été assis ici à récurer sur Internet pour des réponses, je suis tombé au hasard sur le problème. Je n'ai pas compris la solution, seulement une solution de contournement, mais au moins je suis en marche. L'un des paramètres que j'étais passés au programme lui faisait suspendre. J'ai pris le paramètre, ce qui n'était pas optimal pour ce que j'essaie de faire, mais le programme ne pendne plus. Ce même paramètre fonctionnait sur ma boîte Win7, alors je ne pensais même pas que cela y faisait partie. Oh bien, merci pour l'aide!
Quel type de paramètre avez-vous supprimé? J'ai eu des problèmes étranges et stupides avec des blocages à Java (tous avaient une chose en commun: lire du système.in)