Comportement mystérieux de multiprocessing

Version imprimable

11/04/2012, 15h11
Captain'Flam

Comportement mystérieux de multiprocessing
Bonjour,

en faisant des essais avec le module multiprocessing, je suis tombé sur un comportement des plus bizarres et tout à fait contrariant !
Voici un bout de code minimal qui met en évidence le problème :
Code:

1 2 3 4 5 6 7 8 9 from multiprocessing import Process def f ( name ): for i in xrange( 10 ): print name,i p = Process(target=f, args=('from root',)) p.start() p.join()
Quand le process est lancé, c'est la catastrophe !
Il part dans une en boucle infinie (en affichant plein de fois les 10 lignes attendues) en occupant tout le CPU et en affichant de temps en temps :
Code:

1 2 3 Unable to register TclNotifier window class This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
Qu'ai je fait de mal ?
Qu'est qu'un comprend-il le fin mot de l'histoire ?

Merci d'avance...
Hadrien

Hello,
Tout ce que je peux dire c'est que chez moi ça fonctionne correctement :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
$ cat pro.py
from multiprocessing import Process
 
def f ( name ):
    for i in xrange( 10 ):
        print name,i
 
p = Process(target=f, args=('from root',))
p.start()
p.join()
 
$ python pro.py 
from root 0
from root 1
from root 2
from root 3
from root 4
from root 5
from root 6
from root 7
from root 8
from root 9
 
$ python --version
Python 2.6.5

Bonjour,

J'ai essayé avec une console (cmd sous Windows) pour être sûr de ne pas tomber dans un pb d'outil de développement. Et ça ne fonctionne pas non plus (boucle infinie), sauf quand je change le code comme suit:
Code:

1 2 3 4 5 6 7 8 9 10 from multiprocessing import Process def f(name): for i in xrange( 10 ): print name,i if __name__ == '__main__': p = Process(target=f, args=('from root',)) p.start() p.join()
Ce qui m'a fait essayer ça, c'est de voir dans la doc que les exemples utilisent le "if __name__ == '__main__':"

Quand à dire pourquoi ça marche comme ça...

[Edit]: il y a une explication dans la doc. Extrait:

Citation:

For an explanation of why (on Windows) the if __name__ == '__main__' part is necessary, see Programming guidelines.

Le reste de l'explication ici: "16.6.3.2. Windows" de la doc du module multiprocessing.

11/04/2012, 18h58
Captain'Flam

Merci à tous de vos efforts !

Je n'ai qu'un mot à dire : BEARK ! :vomi:
C'est super moche ce truc qui dépend de global/pas global...
Autant dire que ce module est inutilisable en cas réel sous Windaube !

Tant pis, je me débrouillerais autrement... :cry:
11/04/2012, 21h12
wiztricks

Salut,

Sous U**X, la bibliothèque peut s'appuyer sur "fork" pour créer les autres process. Sous Windows, fork n'existant pas, c'est "emulé" en recopiant les globals avec des "soucis" côté état des files descriptors.

Ensuite, les mises à jours se font via IPC => sauf cas particulier le 'bootstrap' de l'application risque de ne pas être "portable" entre Windows et Linux.

La bibliothèque concurrent.futures ajoute une couche d'abstraction "au dessus" de tout çà qui mérite le détour si le modèle de programmation parallèle est de type Worker's Queue.

Ceci dit, la programmation parallèle avec les threads n'est pas simple, avec les process séparés c'est encore plus compliqué et donc à n'utiliser que si le problème à résoudre le "mérite" et non pour le fun.

Cordialement,
- W