- initialiser 1 tableau contenant des urls.
- lancer simultan=E9ment 3 processus qui vont chacun t=E9l=E9charger 1 url =
de
la liste.
Je souhaite avoir toujours 3 processus (donc avec une file d'attente) :
d=E8s qu'une url est t=E9l=E9charg=E9e, alors son processus est termin=E9 (=
ferm=E9),
ce qui va permettre l'ouverture d'un nouveau processus.
J'ai essay=E9 de g=E9rer cela avec des threads mais au bout d'un moment,
j'obtiens une saturation m=E9moire.
Que me conseillez-vous ? (en Perl, et dans la mesure du possible :
portable, je suis sous linux mais... ...)
- initialiser 1 tableau contenant des urls. - lancer simultanément 3 processus qui vont chacun télécharger 1 url > de la liste.
Ceci vient d'être discuté ici, cf. la discussion "lancer N processus sur M" (ou un titre approchant).
Bonne chance,
-- Denis
Paul Gaborit
À (at) 4 Feb 2005 05:43:50 -0800, (Paul) écrivait (wrote):
Je souhaite faire le script suivant :
- initialiser 1 tableau contenant des urls. - lancer simultanément 3 processus qui vont chacun télécharger 1 url > de la liste.
Je souhaite avoir toujours 3 processus (donc avec une file d'attente) : dès qu'une url est téléchargée, alors son processus est terminé ( > fermé), ce qui va permettre l'ouverture d'un nouveau processus.
J'ai essayé de gérer cela avec des threads mais au bout d'un moment, j'obtiens une saturation mémoire.
Que me conseillez-vous ? (en Perl, et dans la mesure du possible : portable, je suis sous linux mais... ...)
Pour ce besoin tout à fait particulier, il existe le module LWP::Parallel qui répond exactement (il est tout à fait portable).
On peut aussi tenter le multi-thread ou le multi-processus (ce n'est pas du tout la même approche). Ce sera dur de faire complètement portable dans le cas multi-processus. Ce sera dur de faire du multi-thread si vous ne maîtrisez pas toutes les implications de ce choix (le support du multi-thread est encore expériemental).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) 4 Feb 2005 05:43:50 -0800,
ernond_paul@yahoo.fr (Paul) écrivait (wrote):
Je souhaite faire le script suivant :
- initialiser 1 tableau contenant des urls.
- lancer simultanément 3 processus qui vont chacun télécharger 1 url > de la liste.
Je souhaite avoir toujours 3 processus (donc avec une file d'attente) :
dès qu'une url est téléchargée, alors son processus est terminé ( > fermé),
ce qui va permettre l'ouverture d'un nouveau processus.
J'ai essayé de gérer cela avec des threads mais au bout d'un moment,
j'obtiens une saturation mémoire.
Que me conseillez-vous ? (en Perl, et dans la mesure du possible :
portable, je suis sous linux mais... ...)
Pour ce besoin tout à fait particulier, il existe le module LWP::Parallel qui
répond exactement (il est tout à fait portable).
On peut aussi tenter le multi-thread ou le multi-processus (ce n'est pas du
tout la même approche). Ce sera dur de faire complètement portable dans le cas
multi-processus. Ce sera dur de faire du multi-thread si vous ne maîtrisez pas
toutes les implications de ce choix (le support du multi-thread est encore
expériemental).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) 4 Feb 2005 05:43:50 -0800, (Paul) écrivait (wrote):
Je souhaite faire le script suivant :
- initialiser 1 tableau contenant des urls. - lancer simultanément 3 processus qui vont chacun télécharger 1 url > de la liste.
Je souhaite avoir toujours 3 processus (donc avec une file d'attente) : dès qu'une url est téléchargée, alors son processus est terminé ( > fermé), ce qui va permettre l'ouverture d'un nouveau processus.
J'ai essayé de gérer cela avec des threads mais au bout d'un moment, j'obtiens une saturation mémoire.
Que me conseillez-vous ? (en Perl, et dans la mesure du possible : portable, je suis sous linux mais... ...)
Pour ce besoin tout à fait particulier, il existe le module LWP::Parallel qui répond exactement (il est tout à fait portable).
On peut aussi tenter le multi-thread ou le multi-processus (ce n'est pas du tout la même approche). Ce sera dur de faire complètement portable dans le cas multi-processus. Ce sera dur de faire du multi-thread si vous ne maîtrisez pas toutes les implications de ce choix (le support du multi-thread est encore expériemental).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Patrick Mevzek
- lancer simultanément 3 processus qui vont chacun télécharger 1 url = de la liste.
Cf l'article ``A forking parallel link checker'' de Randal L. Schwartz sur http://www.stonehenge.com/merlyn/LinuxMag/col16.html
Ou sinon une introduction à POE, ``Doing many things at once'' http://www.stonehenge.com/merlyn/LinuxMag/col41.html
POE étant, en *très* simplifié, un framework Perl permettant d'avoir l'équivalent de threads sans aucun support dans l'OS, mais c'est du multitache collaboratif, alors qu'une solution basée sur fork comme la précédente, est en préemptif.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- lancer simultanément 3
processus qui vont chacun télécharger 1 url = de la liste.
Cf l'article ``A forking parallel link checker'' de Randal L. Schwartz
sur http://www.stonehenge.com/merlyn/LinuxMag/col16.html
Ou sinon une introduction à POE, ``Doing many things at once''
http://www.stonehenge.com/merlyn/LinuxMag/col41.html
POE étant, en *très* simplifié, un framework Perl permettant d'avoir
l'équivalent de threads sans aucun support dans l'OS, mais c'est du
multitache collaboratif, alors qu'une solution basée sur fork comme la
précédente, est en préemptif.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- lancer simultanément 3 processus qui vont chacun télécharger 1 url = de la liste.
Cf l'article ``A forking parallel link checker'' de Randal L. Schwartz sur http://www.stonehenge.com/merlyn/LinuxMag/col16.html
Ou sinon une introduction à POE, ``Doing many things at once'' http://www.stonehenge.com/merlyn/LinuxMag/col41.html
POE étant, en *très* simplifié, un framework Perl permettant d'avoir l'équivalent de threads sans aucun support dans l'OS, mais c'est du multitache collaboratif, alors qu'une solution basée sur fork comme la précédente, est en préemptif.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Emmanuel Florac
Le Fri, 04 Feb 2005 05:43:50 -0800, Paul a écrit :
Que me conseillez-vous ? (en Perl, et dans la mesure du possible : portable, je suis sous linux mais... ...)
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut forker...
-- Si non confectus non reficiat.
Le Fri, 04 Feb 2005 05:43:50 -0800, Paul a écrit :
Que me conseillez-vous ? (en Perl, et dans la mesure du possible :
portable, je suis sous linux mais... ...)
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut forker...
Que me conseillez-vous ? (en Perl, et dans la mesure du possible : portable, je suis sous linux mais... ...)
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut forker...
use threads;
Jérémy JUST
On Fri, 04 Feb 2005 21:44:08 GMT Manu wrote:
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut forker...
use threads;
Ouais, c'est pas parce qu'on sait écrire le pragma qu'on s'en sert avec facilité. J'appuie le propos d'Emmanuel: si les processus n'ont pas à partager de données en mémoire, il est beaucoup plus simple (et souvent économique) de forker.
Or, en l'occurrence, je n'ai pas l'impression que les processus partagent grand chose ici (ils partent chacun avec leur URL sous le bras et ils s'en occupent dans leur coin).
-- Jérémy JUST
On Fri, 04 Feb 2005 21:44:08 GMT
Manu <noemail@noemail.no> wrote:
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut
forker...
use threads;
Ouais, c'est pas parce qu'on sait écrire le pragma qu'on s'en sert
avec facilité.
J'appuie le propos d'Emmanuel: si les processus n'ont pas à partager
de données en mémoire, il est beaucoup plus simple (et souvent
économique) de forker.
Or, en l'occurrence, je n'ai pas l'impression que les processus
partagent grand chose ici (ils partent chacun avec leur URL sous le
bras et ils s'en occupent dans leur coin).
Sous Linux l'utilisation des threads perl est une plaie. Mieux vaut forker...
use threads;
Ouais, c'est pas parce qu'on sait écrire le pragma qu'on s'en sert avec facilité. J'appuie le propos d'Emmanuel: si les processus n'ont pas à partager de données en mémoire, il est beaucoup plus simple (et souvent économique) de forker.
Or, en l'occurrence, je n'ai pas l'impression que les processus partagent grand chose ici (ils partent chacun avec leur URL sous le bras et ils s'en occupent dans leur coin).
