Suite =E0 mes recherches, j'ai d=E9couvert que c'est une limitation (un
bug?) de Python
http://www.mail-archive.com/python-dev@python.org/msg24747.html
=E7a marche effectivement bien quand on sort le import du thread.
Le probl=E8me c'est que je ne peux pas utiliser la librairie mysqldb ou
sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des
import au sein des fonctions et m=E9thodes.
Rien ne t'empêche de faire suivre ton import par les import "d'intérieur des fonctions" du module importé. Anticiper les imports, en somme.
@+ -- Michel Claveau
NicolasP
Le 03/05/2010 18:18, Michel Claveau - MVP a écrit :
Salut !
Rien ne t'empêche de faire suivre ton import par les import "d'intérieur des fonctions" du module importé. Anticiper les imports, en somme.
@+
Mais dans ce cas, il faut connaitre les imports à faire... C'est pas vraiment sûr comme solution ça. Une évolution de la librairie utilisée et patatras !
Nicolas
Le 03/05/2010 18:18, Michel Claveau - MVP a écrit :
Salut !
Rien ne t'empêche de faire suivre ton import par les import "d'intérieur
des fonctions" du module importé. Anticiper les imports, en somme.
@+
Mais dans ce cas, il faut connaitre les imports à faire...
C'est pas vraiment sûr comme solution ça.
Une évolution de la librairie utilisée et patatras !
Le 03/05/2010 18:18, Michel Claveau - MVP a écrit :
Salut !
Rien ne t'empêche de faire suivre ton import par les import "d'intérieur des fonctions" du module importé. Anticiper les imports, en somme.
@+
Mais dans ce cas, il faut connaitre les imports à faire... C'est pas vraiment sûr comme solution ça. Une évolution de la librairie utilisée et patatras !
Nicolas
NicolasP
Le 03/05/2010 14:52, Chris a écrit :
Bonjour,
Suite à mes recherches, j'ai découvert que c'est une limitation (un bug?) de Python http://www.mail-archive.com//msg24747.html
ça marche effectivement bien quand on sort le import du thread. Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des import au sein des fonctions et méthodes.
Merci de ton aide news1234
Chris
Si les threads ne le font pas, tu peux toujours utiliser les processes. C'est un peu plus compliqué pour communiquer entre processes mais : - Ca t'obliges à coder correctement la communication inter-processes (alors que tu peux faire du vrai cochon avec les threads en pensant que ça marche bien). - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). - Tu peux déporter l'exécution des processes sur d'autres machines (à vérifier).
Nicolas
Le 03/05/2010 14:52, Chris a écrit :
Bonjour,
Suite à mes recherches, j'ai découvert que c'est une limitation (un
bug?) de Python
http://www.mail-archive.com/python-dev@python.org/msg24747.html
ça marche effectivement bien quand on sort le import du thread.
Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou
sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des
import au sein des fonctions et méthodes.
Merci de ton aide news1234
Chris
Si les threads ne le font pas, tu peux toujours utiliser les processes.
C'est un peu plus compliqué pour communiquer entre processes mais :
- Ca t'obliges à coder correctement la communication inter-processes (alors que tu peux faire du vrai cochon avec les threads en pensant que ça marche bien).
- Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur).
- Tu peux déporter l'exécution des processes sur d'autres machines (à vérifier).
Suite à mes recherches, j'ai découvert que c'est une limitation (un bug?) de Python http://www.mail-archive.com//msg24747.html
ça marche effectivement bien quand on sort le import du thread. Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des import au sein des fonctions et méthodes.
Merci de ton aide news1234
Chris
Si les threads ne le font pas, tu peux toujours utiliser les processes. C'est un peu plus compliqué pour communiquer entre processes mais : - Ca t'obliges à coder correctement la communication inter-processes (alors que tu peux faire du vrai cochon avec les threads en pensant que ça marche bien). - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). - Tu peux déporter l'exécution des processes sur d'autres machines (à vérifier).
Nicolas
Chris
Salut,
Ok merci pour vos retours, je vais essayer d'utiliser la librairie multiprocessing. Je vous tiendrais au courant si ça fonctionne mieux.
Pour la petite histoire, je voulais simplement utiliser mon orm dans un thread pour éviter le gel de mon GUI (wxpython) et envisager des barres de chargement. Les processes peuvent donc être une solution valable dans mon cas.
Merci à vous deux
Salut,
Ok merci pour vos retours, je vais essayer d'utiliser la librairie
multiprocessing.
Je vous tiendrais au courant si ça fonctionne mieux.
Pour la petite histoire, je voulais simplement utiliser mon orm dans
un thread pour éviter le gel de mon GUI (wxpython) et envisager des
barres de chargement.
Les processes peuvent donc être une solution valable dans mon cas.
Ok merci pour vos retours, je vais essayer d'utiliser la librairie multiprocessing. Je vous tiendrais au courant si ça fonctionne mieux.
Pour la petite histoire, je voulais simplement utiliser mon orm dans un thread pour éviter le gel de mon GUI (wxpython) et envisager des barres de chargement. Les processes peuvent donc être une solution valable dans mon cas.
Merci à vous deux
Bruno Desthuilliers
NicolasP a écrit :
Le 03/05/2010 14:52, Chris a écrit :
Bonjour,
Suite à mes recherches, j'ai découvert que c'est une limitation (un bug?) de Python http://www.mail-archive.com//msg24747.html
ça marche effectivement bien quand on sort le import du thread. Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des import au sein des fonctions et méthodes.
Mmm... Il me semble pourtant bien qu'il est possible d'utiliser sqlalchemy dans des applications multithreadées. C'est même un cas d'utilisation assez courant dans les applis web.
NicolasP a écrit :
Le 03/05/2010 14:52, Chris a écrit :
Bonjour,
Suite à mes recherches, j'ai découvert que c'est une limitation (un
bug?) de Python
http://www.mail-archive.com/python-dev@python.org/msg24747.html
ça marche effectivement bien quand on sort le import du thread.
Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou
sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des
import au sein des fonctions et méthodes.
Mmm... Il me semble pourtant bien qu'il est possible d'utiliser
sqlalchemy dans des applications multithreadées. C'est même un cas
d'utilisation assez courant dans les applis web.
Suite à mes recherches, j'ai découvert que c'est une limitation (un bug?) de Python http://www.mail-archive.com//msg24747.html
ça marche effectivement bien quand on sort le import du thread. Le problème c'est que je ne peux pas utiliser la librairie mysqldb ou sqlalchemy sans bloquer mon thread car ces 2 librairies comportent des import au sein des fonctions et méthodes.
Mmm... Il me semble pourtant bien qu'il est possible d'utiliser sqlalchemy dans des applications multithreadées. C'est même un cas d'utilisation assez courant dans les applis web.
Daireaux Jean-Baptiste
NicolasP a écrit :
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Si non, cela me semble louche comme remarque ...
J.B.D.
NicolasP a écrit :
...
- Tu profites de la puissance de tous les coeurs de ton processeur
(alors qu'en multi-threads tu n'utilises qu'un coeur).
...
Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle
spécifiquement python ?
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Si non, cela me semble louche comme remarque ...
J.B.D.
NicolasP
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Oui. Et plus particulièrement CPython. Pour les autres implémentations de Python, je ne sais pas. CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça. CPython crée bien un thread système par thread python. Mais, à cause du GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être pénalisant par rapport à l'utilisation d'un seul thread (la commutation de thread prends du temps). C'est le cas pour du calcul distribué par exemple.
Pour une explication un peu plus poussée, voir http://www.python.org/dev/peps/pep-0371/ Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers" dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais permettent de faire du vrai multitâche.
Nicolas
J.B.D.
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
...
- Tu profites de la puissance de tous les coeurs de ton processeur
(alors qu'en multi-threads tu n'utilises qu'un coeur).
...
Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle
spécifiquement python ?
Oui.
Et plus particulièrement CPython. Pour les autres implémentations de Python, je ne sais pas.
CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça.
CPython crée bien un thread système par thread python. Mais, à cause du GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être pénalisant par rapport à l'utilisation d'un seul thread (la commutation de thread prends du temps). C'est le cas pour du calcul distribué par exemple.
Pour une explication un peu plus poussée, voir http://www.python.org/dev/peps/pep-0371/
Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers" dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais permettent de faire du vrai multitâche.
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Oui. Et plus particulièrement CPython. Pour les autres implémentations de Python, je ne sais pas. CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça. CPython crée bien un thread système par thread python. Mais, à cause du GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être pénalisant par rapport à l'utilisation d'un seul thread (la commutation de thread prends du temps). C'est le cas pour du calcul distribué par exemple.
Pour une explication un peu plus poussée, voir http://www.python.org/dev/peps/pep-0371/ Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers" dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais permettent de faire du vrai multitâche.
Nicolas
J.B.D.
Daireaux Jean-Baptiste
NicolasP a écrit :
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Oui. Et plus particulièrement CPython. Pour les autres implémentations de Python, je ne sais pas. CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça. CPython crée bien un thread système par thread python. Mais, à cause du GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être pénalisant par rapport à l'utilisation d'un seul thread (la commutation de thread prends du temps). C'est le cas pour du calcul distribué par exemple.
Pour une explication un peu plus poussée, voir http://www.python.org/dev/peps/pep-0371/ Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers" dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais permettent de faire du vrai multitâche.
Nicolas
Merci pour le complément d'information. J.B.D.
NicolasP a écrit :
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
...
- Tu profites de la puissance de tous les coeurs de ton processeur
(alors qu'en multi-threads tu n'utilises qu'un coeur).
...
Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle
spécifiquement python ?
Oui.
Et plus particulièrement CPython. Pour les autres implémentations de
Python, je ne sais pas.
CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça.
CPython crée bien un thread système par thread python. Mais, à cause du
GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul
coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html
chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être
pénalisant par rapport à l'utilisation d'un seul thread (la commutation
de thread prends du temps). C'est le cas pour du calcul distribué par
exemple.
Pour une explication un peu plus poussée, voir
http://www.python.org/dev/peps/pep-0371/
Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers"
dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais
permettent de faire du vrai multitâche.
Le 05/05/2010 13:02, Daireaux Jean-Baptiste a écrit :
NicolasP a écrit :
... - Tu profites de la puissance de tous les coeurs de ton processeur (alors qu'en multi-threads tu n'utilises qu'un coeur). ... Nicolas
Ne connaissant pas bien python, cette remarque concerne-t-elle spécifiquement python ?
Oui. Et plus particulièrement CPython. Pour les autres implémentations de Python, je ne sais pas. CPython est l'interpréteur du langage Python le plus couramment utilisé.
Si non, cela me semble louche comme remarque ...
C'est en fait un peu plus compliqué que ça. CPython crée bien un thread système par thread python. Mais, à cause du GIL, un seul thread fonctionne à la fois. C'est donc comme si un seul coeur était utilisé.
Pour une explication rapide, voir http://linuxgazette.net/107/pai.html chapitre 3.
Il y a des benchmarks qui montrent qu'utiliser les threads peut être pénalisant par rapport à l'utilisation d'un seul thread (la commutation de thread prends du temps). C'est le cas pour du calcul distribué par exemple.
Pour une explication un peu plus poussée, voir http://www.python.org/dev/peps/pep-0371/ Pour les résultats des benchmarks, rechercher "50000 Fibonacci numbers" dans la page.
Les process prennent plus de temps à s'initialiser que les threads mais permettent de faire du vrai multitâche.
