je connais Python depuis d=E9j=E0 pas mal de temps... mais je n'avais jamai=
s =E9t=E9 confront=E9 aux probl=E8mes de parall=E8lisme.
En fait je voudrais avoir 2 scripts diff=E9rents
un premier script qui r=E9cup=E8re des donn=E9es sur le net (JSON, CSV...)
ce script pourra =E9ventuellement lancer plusieurs threads pour r=E9cup=E9r=
er en parall=E8le chaque donn=E9e
(est-ce une bonne id=E9e ??)
Si le script rencontre une erreur de r=E9cup=E9ration d'un des =E9l=E9ments=
il devra le "marquer"
il lit au d=E9but un fichier CSV contenant les informations permettant de s=
avoir ce qu'il doit r=E9cup=E9rer,
"marquer" les =E9l=E9ments ayant pos=E9 probl=E8me serait par exemple mettr=
e une donn=E9e bool=E9enne pour chaque info =E0 r=E9cup=E9rer.
un deuxi=E8me script doit se charger d'effectuer des calculs sur les donn=
=E9es r=E9cup=E9r=E9es (celles qui n'ont pas =E9t=E9 marqu=E9es comme ayant=
pos=E9 un probl=E8me)
(mais uniquement apr=E8s que le premier script ai termin=E9 son travail (r=
=E9cup=E9rer l'ensemble des donn=E9es)
Comment g=E9rer cela ?
Avez-vous quelques conseils de lecture (si possible gratuite) pour comprend=
re ces notions de verrous, s=E9maphore, mutex (il semble que ce dernier n'e=
xiste plus dans Python 3)...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent Pointal
Psylle du Poitou wrote:
Bonjour,
je connais Python depuis déjà pas mal de temps... mais je n'avais jamais été confronté aux problèmes de parallèlisme.
En fait je voudrais avoir 2 scripts différents
un premier script qui récupère des données sur le net (JSON, CSV...) ce script pourra éventuellement lancer plusieurs threads pour récupérer en parallèle chaque donnée (est-ce une bonne idée ??)
S'il y en a trop, il vaudra peut-être mieux s'orienter vers des solutions comme twisted (http://twistedmatrix.com/trac/).
Si le script rencontre une erreur de récupération d'un des éléments il devra le "marquer" il lit au début un fichier CSV contenant les informations permettant de savoir ce qu'il doit récupérer, "marquer" les éléments ayant posé problème serait par exemple mettre une donnée booléenne pour chaque info à récupérer.
un deuxième script doit se charger d'effectuer des calculs sur les données récupérées (celles qui n'ont pas été marquées comme ayant posé un problème) (mais uniquement après que le premier script ai terminé son travail (récupérer l'ensemble des données)
Comment gérer cela ?
La class Queue gère la synchronisation pour toi http://docs.python.org/3.3/library/queue.html
"y'a plus qu'à" créer des threads qui se chargent de lancer les requêtes et de placer les résultats (données ou indication d'erreur) sous la forme de ton choix (tuple, classe perso) dans la queue.
Et un thread qui prend ce qui arrive dans la queue et lance les traitements.
Tu peux même imaginer en entrée une queue dans laquelle tu passes les requêtes, et que tes threads de récupération
Avez-vous quelques conseils de lecture (si possible gratuite) pour comprendre ces notions de verrous, sémaphore, mutex
En anglais, python threading example sur google devrait donner des pistes. Je trouve même des liens vers des pages en français http://python.developpez.com/faq/?page=Thread
mutex (il semble que ce dernier n'existe plus dans Python 3)...
Mutex ==> Lock (ou RLock s'il faut qu'il soit réentrant), existe toujours en Python3 (heureusement, c'est une des briques de base).
mutex = threading.Lock() with mutex: # ici le code qui est en section protégée
(vive "with")
Merci d'avance
-- Laurent POINTAL -
Psylle du Poitou wrote:
Bonjour,
je connais Python depuis déjà pas mal de temps... mais je n'avais jamais
été confronté aux problèmes de parallèlisme.
En fait je voudrais avoir 2 scripts différents
un premier script qui récupère des données sur le net (JSON, CSV...)
ce script pourra éventuellement lancer plusieurs threads pour récupérer en
parallèle chaque donnée (est-ce une bonne idée ??)
S'il y en a trop, il vaudra peut-être mieux s'orienter vers des solutions
comme twisted (http://twistedmatrix.com/trac/).
Si le script rencontre une erreur de récupération d'un des éléments il
devra le "marquer" il lit au début un fichier CSV contenant les
informations permettant de savoir ce qu'il doit récupérer, "marquer" les
éléments ayant posé problème serait par exemple mettre une donnée
booléenne pour chaque info à récupérer.
un deuxième script doit se charger d'effectuer des calculs sur les données
récupérées (celles qui n'ont pas été marquées comme ayant posé un
problème) (mais uniquement après que le premier script ai terminé son
travail (récupérer l'ensemble des données)
Comment gérer cela ?
La class Queue gère la synchronisation pour toi
http://docs.python.org/3.3/library/queue.html
"y'a plus qu'à" créer des threads qui se chargent de lancer les requêtes et
de placer les résultats (données ou indication d'erreur) sous la forme de
ton choix (tuple, classe perso) dans la queue.
Et un thread qui prend ce qui arrive dans la queue et lance les traitements.
Tu peux même imaginer en entrée une queue dans laquelle tu passes les
requêtes, et que tes threads de récupération
Avez-vous quelques conseils de lecture (si possible gratuite) pour
comprendre ces notions de verrous, sémaphore, mutex
En anglais, python threading example sur google devrait donner des pistes.
Je trouve même des liens vers des pages en français
http://python.developpez.com/faq/?page=Thread
mutex (il semble que ce
dernier n'existe plus dans Python 3)...
Mutex ==> Lock (ou RLock s'il faut qu'il soit réentrant), existe toujours en
Python3 (heureusement, c'est une des briques de base).
mutex = threading.Lock()
with mutex:
# ici le code qui est en section protégée
je connais Python depuis déjà pas mal de temps... mais je n'avais jamais été confronté aux problèmes de parallèlisme.
En fait je voudrais avoir 2 scripts différents
un premier script qui récupère des données sur le net (JSON, CSV...) ce script pourra éventuellement lancer plusieurs threads pour récupérer en parallèle chaque donnée (est-ce une bonne idée ??)
S'il y en a trop, il vaudra peut-être mieux s'orienter vers des solutions comme twisted (http://twistedmatrix.com/trac/).
Si le script rencontre une erreur de récupération d'un des éléments il devra le "marquer" il lit au début un fichier CSV contenant les informations permettant de savoir ce qu'il doit récupérer, "marquer" les éléments ayant posé problème serait par exemple mettre une donnée booléenne pour chaque info à récupérer.
un deuxième script doit se charger d'effectuer des calculs sur les données récupérées (celles qui n'ont pas été marquées comme ayant posé un problème) (mais uniquement après que le premier script ai terminé son travail (récupérer l'ensemble des données)
Comment gérer cela ?
La class Queue gère la synchronisation pour toi http://docs.python.org/3.3/library/queue.html
"y'a plus qu'à" créer des threads qui se chargent de lancer les requêtes et de placer les résultats (données ou indication d'erreur) sous la forme de ton choix (tuple, classe perso) dans la queue.
Et un thread qui prend ce qui arrive dans la queue et lance les traitements.
Tu peux même imaginer en entrée une queue dans laquelle tu passes les requêtes, et que tes threads de récupération
Avez-vous quelques conseils de lecture (si possible gratuite) pour comprendre ces notions de verrous, sémaphore, mutex
En anglais, python threading example sur google devrait donner des pistes. Je trouve même des liens vers des pages en français http://python.developpez.com/faq/?page=Thread
mutex (il semble que ce dernier n'existe plus dans Python 3)...
Mutex ==> Lock (ou RLock s'il faut qu'il soit réentrant), existe toujours en Python3 (heureusement, c'est une des briques de base).
mutex = threading.Lock() with mutex: # ici le code qui est en section protégée
(vive "with")
Merci d'avance
-- Laurent POINTAL -
Psylle du Poitou
Merci pour vos conseils...
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue permet-elle de gérer l'attente du script "consommateur" de données tant que le script "producteur" de données n'a pas fini..
J'ai l'impression que c'est juste pour des threads qui sont lancés au sei n d'un même script
Merci pour vos conseils...
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue permet-elle de gérer l'attente du script "consommateur" de données tant que le script "producteur" de données n'a pas fini..
J'ai l'impression que c'est juste pour des threads qui sont lancés au sei n d'un même script
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue permet-elle de gérer l'attente du script "consommateur" de données tant que le script "producteur" de données n'a pas fini..
J'ai l'impression que c'est juste pour des threads qui sont lancés au sei n d'un même script
Laurent Pointal
Psylle du Poitou wrote:
Merci pour vos conseils...
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue permet-elle de gérer l'attente du script "consommateur" de données tant que le script "producteur" de données n'a pas fini..
C'est ça.
J'ai l'impression que c'est juste pour des threads qui sont lancés au sein d'un même script
Oui. Pour faire des transferts comme cela, je ne vois a priori pas l'intérêt de faire du multiprocessing. Ceci dit, rien ne l'empêche, juste qu'il faut prévoir ensuite la transmission des données entre processus de récupération et processus de traitement, c'est encore autre chose par rapport à un fonctionnement dans un même processus.
-- Laurent POINTAL -
Psylle du Poitou wrote:
Merci pour vos conseils...
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes
besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue
permet-elle de gérer l'attente du script "consommateur" de données tant
que le script "producteur" de données n'a pas fini..
C'est ça.
J'ai l'impression que c'est juste pour des threads qui sont lancés au sein
d'un même script
Oui. Pour faire des transferts comme cela, je ne vois a priori pas l'intérêt
de faire du multiprocessing. Ceci dit, rien ne l'empêche, juste qu'il faut
prévoir ensuite la transmission des données entre processus de récupération
et processus de traitement, c'est encore autre chose par rapport à un
fonctionnement dans un même processus.
pour ce qui est de Twisted ça me semble un peu trop gros par rapport à mes besoins
Par contre il y a un point que je n'ai pas bien compris... la classe Queue permet-elle de gérer l'attente du script "consommateur" de données tant que le script "producteur" de données n'a pas fini..
C'est ça.
J'ai l'impression que c'est juste pour des threads qui sont lancés au sein d'un même script
Oui. Pour faire des transferts comme cela, je ne vois a priori pas l'intérêt de faire du multiprocessing. Ceci dit, rien ne l'empêche, juste qu'il faut prévoir ensuite la transmission des données entre processus de récupération et processus de traitement, c'est encore autre chose par rapport à un fonctionnement dans un même processus.
-- Laurent POINTAL -
Psylle du Poitou
En fait l'idée c'est que j'ai plusieurs scripts qui peuvent consommer (di fféremment mes données) et un seul qui les "produit".
Le problème c'est que je ne veux pas qu'un consommateur consomme les donn ées quand elles n'ont pas toutes été mise à jour...
En fait l'idée c'est que j'ai plusieurs scripts qui peuvent consommer (di fféremment mes données)
et un seul qui les "produit".
Le problème c'est que je ne veux pas qu'un consommateur consomme les donn ées quand elles n'ont pas toutes été mise à jour...
En fait l'idée c'est que j'ai plusieurs scripts qui peuvent consommer (di fféremment mes données) et un seul qui les "produit".
Le problème c'est que je ne veux pas qu'un consommateur consomme les donn ées quand elles n'ont pas toutes été mise à jour...
Psylle du Poitou
je ne vois a priori pas l'intérêt de faire du multiprocessing.
J'oubliai de préciser un point qui justifie cette architecture...
Mon "producteur" de données sera lancée en prod et ne sera "jamais" arr êté... par contre mes consommateurs sont des scripts qui ne sont pas encore tous a u point... donc j'ai besoin de pouvoir les lancer à la demande, les stopper, etc... tout ça pendant que le "producteur" continue à faire juste son job... r écupérer les données
je ne vois a priori pas l'intérêt de faire du multiprocessing.
J'oubliai de préciser un point qui justifie cette architecture...
Mon "producteur" de données sera lancée en prod et ne sera "jamais" arr êté...
par contre mes consommateurs sont des scripts qui ne sont pas encore tous a u point...
donc j'ai besoin de pouvoir les lancer à la demande, les stopper, etc...
tout ça pendant que le "producteur" continue à faire juste son job... r écupérer les données
je ne vois a priori pas l'intérêt de faire du multiprocessing.
J'oubliai de préciser un point qui justifie cette architecture...
Mon "producteur" de données sera lancée en prod et ne sera "jamais" arr êté... par contre mes consommateurs sont des scripts qui ne sont pas encore tous a u point... donc j'ai besoin de pouvoir les lancer à la demande, les stopper, etc... tout ça pendant que le "producteur" continue à faire juste son job... r écupérer les données
