Discussion :

[Johan.Mazel]

J'ai un programme en python avec une fonction que je veux pouvoir éxécuter plusieurs fois en parallèle. Or, cette fonction contient un appel à un fonction de bash (je suis sous Linux) via popen. L'appel à la fonction est donc bloquant.
J'ai constaté que si je fait juste n threads qui éxécute chacun cette fonction, ceux-ci s'éxécutent les uns à la suite de l'autre et non en parallèle.
D'après ce que j'ai lu sur internet c'est normal. Il faudrait que j'utilise des process via os.fork().
Ce lien explique comment créer un processus fils. Le problème c'est que j'ai besoin de créer n processus fils et j'ai du mal à concevoir ma structure de données et mon algorithme pour lancer mes n process.
Je pense créer un tableau d'entier pour pouvoir stocker tous les pids et attendre tous mes process. Mais cela ne résoud pas le problème du lancement des n process.
Si vous avez des liens et/ou des exemples de programmes faisant ce travail, je suis preneur.
Merci

[mchk0123]

Salut,

Il y a quelque chose que je ne comprends pas, si tu fait un popen dans un thread, pourquoi cela bloquerait-il les autres threads ???
Normalement ils devraient continuer à s'exécuter. Tu pourrais ainsi éviter de forker pour créer des processus (ce qui est plus lourd à mettre en place). Il y a surement quelque chose qui pose pb. dans ton code.

[Johan.Mazel]

Bah en fait, c'est juste une constatation pratique.
Le fait est que lorsque je lance mon programme, la durée d'éxécution est quasiment la même entre 50 threads et 50 fois la fonction du threads lancée à la suite.
Et surtout, j'ai récupéré un lien qui disait que popen bloquait l'éxécution parallèle des threads et que pour avoir du parallélisme, il fallait passer par des process.
Mais, je vais rejeter un coup d'oeil au code.

[mchk0123]

Première page de man trouvée par Google sur popen :

La fonction popen() engendre un processus en créant un tube (pipe), exécutant un fork(), et en invoquant le shell. Comme un tube est unidirectionnel par définition, l'argument type doit indiquer seulement une lecture ou une écriture, et non pas les deux. Le flux correspondant sera ouvert en lecture seule ou écriture seule.

N'oublie pas non plus de faire un pclose() pour fermer le flux ET SUROUT PAS de fclose (d'après ce qui est dit dans cette page de manuel).

[Johan.Mazel]

Bon, en fait j'ai résolu ce problème. Je suis arrivé à faire des threads qui s'éxécute en parallèle.

Mais j'ai un autre problème. En fait chaque thread lance des pings pour trouver des adrresses IP valides jusqu'à ce que le nombre d'IP demandées soit atteint. Et dès que le nombre de threads augmente (en gros, dès qu'il est supérieur à 10), j'ai l'erreur suivante : connect: Argument invalide.
Je suppose que les threads étant trop nombreux, ils arrivent pas à tous lancer les Ping via Popen.
Comment puis-je contourner ce problème ?

[mchk0123]

Non je ne pense pas. D'après le message d'erreur, le problème se situerai plutôt au niveau des pipes et pas des thread. J'avoue que je ne vois pas vraiment de solution. Tout ce que je peux te dire c'est de chercher peut-être du côté des limites du système sur le nombre max. de sockets ouvertes en même temps ou nombre max de descripteur de fichiers.

[Johan.Mazel]

Je suis quasi sûr que ça vient des sockets car en fait, le problème se produit lorsque je lance Popen sur le ping. Je récupère alors 0 lignes sur le résultat de la commande ping alors qu'en théorie (et même en cas de timeout) je devrais récupérer au moins 5 ou 6 lignes.

En fait, c'est comme ça que j'ai trouvé le problème à l'origine : l'absence de ligne dans le résultat faisait planter mon programme d'analyse Là j'ai corrigé pour ne pas traiter le résultat de la commande en cas d'absence de ligne, mais c'est pas pour ça que j'ai plus l'erreur : connect: Argument invalide.

[mchk0123]

Si tu est sous Windows regarde les valeurs renvoyées dans WSAData renvoyé après appel à WSAStartup(). Et dis nous ce que donne iMaxSockets.

[Johan.Mazel]

Bah je suis sous Fedora Core 7 en fait.
Si t'as la commande correspondante...

[mchk0123]

Arg, ... Linux ça remonte à très loin dans mes souvenirs. Si jamais un Linuxien passe par là, qu'il se manifeste.

Au mieux, ce que je peut te dire c'est d'essayer de limiter le nb. de threads à 10. Typiquement on utilise une sémaphore pour ça.

J'y penses, quand tu lance les commandes ping est-ce qu'elles pointent toutes vers le même host ?

Ce que tu peut aussi tester c'est de remplacer la commande ping par un wget (si tu la connais un peu) pour voir si la barre des 10 threads peut être dépassé sans bloquage des sockets. Elles mettent en oeuvre des protocoles fondamentalement différents, et l'une peut très bien bloquer alors que la deuxième non.

[Johan.Mazel]

Pour la limitation à 10, mon but est justement de trouver un maximum d'adresses valides en un minimum de temps, c'est pour ça que je veux utiliser beaucoup de threads.

Pour les Ping, a priori, aucun ping n'est lancé vers une adresse déjà pinguée auparavant.

Pour wget, je viens de survoler le man mais je pense pas que je puisse récupérer les RTT avec cette commande.

[mchk0123]

On s'est mal compris. La command wget n'a pas comme but de remplacer ce que fait un ping.

C'est juste qu'un ping envoi des paquets ICMP qui peuvent être filtrés, ignorés, temporisés par les routeurs et serveurs, ... bref c'est pas ultra-rapide. Au contraire, wget utilise HTTP qui est trés rapide et pas filtré.

Mais tu peut aussi très bien faire un system("ls -1 ./*"); Le but étant de vérifier que ce n'est pas la commande ping qui pose problème.

[Johan.Mazel]

En fait, j'ai trouvé qu'il restait encore une plage d'adresse IP que je générais (aléatoirement) qui étaient invalides et que je scannais quand même.

Pour les sockets, en faisant des tests, j'ai remarqué que je pouvais en faire à peu près 330 sans problème, donc ça ne vient pas de là, c'est sur.

Le problème est donc résolu. J'en ai d'autres sur le feu, mais c'est plus de l'algorithmique et du traitement de résultat de commandes que des problèmes liés au langage.