Est-il possible de faire qu'un code utilisant IO::Socket tel que celui
décrit dans la doc Perl en 42.6.2 au sujet d'un "Client Webget" ne soit
pas bloquant pour le reste du script ?
Notamment le sockaddr_in() qui gèle le déroulement du script si la
machine distante n'est pas accessible.
Y-a-til moyen de réduire le timeout ou, mieux, de faire que cet appel
soit asynchrone (sans parler de l'attente de la réponse ultérieure
puisque dans le premier cas que j'ai à traiter, la réponse du get n'est
pas nécessaire au reste du script - il s'agit juste de déclencher un
autre cgi qui lui vivra sa vie).
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
Il y a des bibliothèques de résolution DNS asynchrones, mais pas distribuées en standard avec Perl il me semble (en fait, je n'en connai pas en Perl / pour Perl, mais je n'ai pas cherché). C'est également faisable purement en Perl, mais pas de manière complètement portable (pour obtenir l'adresse du résolveur local). On peut aussi envisager un processus auxiliaire dédié, mais ça commence à faire beaucoup d'infrastructure, il faudrait peut-être resonger l'architecture si c'est ça.
Asterbing wrote in message
<MPG.1e9101201f0c5b169897aa@news.tiscali.fr>:
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
Il y a des bibliothèques de résolution DNS asynchrones, mais pas distribuées
en standard avec Perl il me semble (en fait, je n'en connai pas en Perl /
pour Perl, mais je n'ai pas cherché). C'est également faisable purement en
Perl, mais pas de manière complètement portable (pour obtenir l'adresse du
résolveur local). On peut aussi envisager un processus auxiliaire dédié,
mais ça commence à faire beaucoup d'infrastructure, il faudrait peut-être
resonger l'architecture si c'est ça.
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
Il y a des bibliothèques de résolution DNS asynchrones, mais pas distribuées en standard avec Perl il me semble (en fait, je n'en connai pas en Perl / pour Perl, mais je n'ai pas cherché). C'est également faisable purement en Perl, mais pas de manière complètement portable (pour obtenir l'adresse du résolveur local). On peut aussi envisager un processus auxiliaire dédié, mais ça commence à faire beaucoup d'infrastructure, il faudrait peut-être resonger l'architecture si c'est ça.
Paul Gaborit
À (at) Sun, 26 Mar 2006 18:03:27 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée, le comportement est hautement non-portable, et Perl empire assez largement les choses : jusqu'à récemment, il n'y avait rien qui soit garanti fonctionner dans un signal handler, et de fait, j'ai pu observer des segfaults de l'interpréteur dans précisément ce cas.
La gestion des signaux s'est largement améliorée avec les versions 5.8.x. En fait avant, elle ne fonctionnait pas (puisque le code attaché au signal s'exécutait n'importe quand et parfois au mauvais moment). Maintenant, elle fonctionne correctement.
Si vous avez constaté des "segmentation faults" avec une version 5.8.x, il serait intéressant de voir le code fautif.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Sun, 26 Mar 2006 18:03:27 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée,
le comportement est hautement non-portable, et Perl empire assez largement
les choses : jusqu'à récemment, il n'y avait rien qui soit garanti
fonctionner dans un signal handler, et de fait, j'ai pu observer des
segfaults de l'interpréteur dans précisément ce cas.
La gestion des signaux s'est largement améliorée avec les versions
5.8.x. En fait avant, elle ne fonctionnait pas (puisque le code
attaché au signal s'exécutait n'importe quand et parfois au mauvais
moment). Maintenant, elle fonctionne correctement.
Si vous avez constaté des "segmentation faults" avec une version
5.8.x, il serait intéressant de voir le code fautif.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Sun, 26 Mar 2006 18:03:27 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée, le comportement est hautement non-portable, et Perl empire assez largement les choses : jusqu'à récemment, il n'y avait rien qui soit garanti fonctionner dans un signal handler, et de fait, j'ai pu observer des segfaults de l'interpréteur dans précisément ce cas.
La gestion des signaux s'est largement améliorée avec les versions 5.8.x. En fait avant, elle ne fonctionnait pas (puisque le code attaché au signal s'exécutait n'importe quand et parfois au mauvais moment). Maintenant, elle fonctionne correctement.
Si vous avez constaté des "segmentation faults" avec une version 5.8.x, il serait intéressant de voir le code fautif.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Asterbing
In article <e06vs5$js0$, nicolas$ says...
my $child = fork; die "fork: $!n" unless defined $child; return if $child;
Attention quand même : il faut aussi faire un wait sur le fils si le père doit tourner pendant longtemps, mais j'ai cru comprendre que ce n'était pas le cas.
Bon, je vais tourner autour de ça. Merci à toi
In article <e06vs5$js0$1@biggoron.nerim.net>, nicolas$george@salle-s.org
says...
my $child = fork;
die "fork: $!n" unless defined $child;
return if $child;
Attention quand même : il faut aussi faire un wait sur le fils si le père
doit tourner pendant longtemps, mais j'ai cru comprendre que ce n'était pas
le cas.
my $child = fork; die "fork: $!n" unless defined $child; return if $child;
Attention quand même : il faut aussi faire un wait sur le fils si le père doit tourner pendant longtemps, mais j'ai cru comprendre que ce n'était pas le cas.
Bon, je vais tourner autour de ça. Merci à toi
Asterbing
In article , says...
La gestion des signaux s'est largement améliorée avec les versions 5.8.x.
J'ai demandé au sysadmin et les serveurs les moins à jour sont ici en 5.00503.
In article <r7veu0s5ds.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
La gestion des signaux s'est largement améliorée avec les versions
5.8.x.
J'ai demandé au sysadmin et les serveurs les moins à jour sont ici en
5.00503.
La gestion des signaux s'est largement améliorée avec les versions 5.8.x.
J'ai demandé au sysadmin et les serveurs les moins à jour sont ici en 5.00503.
Paul Gaborit
À (at) Sun, 26 Mar 2006 19:06:05 +0200, Asterbing écrivait (wrote):
In article , says...
Lorsque vous citez "la" documenation, il vaut mieux citer le(s) titre(s) en question (par exemple "perlfaq9", section "...xxx...")
Bien sûr. Cette documentation est une traduction française dont vous avez écrit l'avant-propos, Paul : <http://perl.enstimac.fr/perl-all-fr- pdf.pdf>. Le chapitre 45.2 pour être le plus large possible.
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45 s'appelle "perlport - écrire du code Perl portable", la section 45.2 "PROBLÈMES" !?!
Le 42.6.2 (précédement cité) parle bien d'un "client Webget" mais le plus important c'est le titre du chapitre "perlipc - Communication inter-processus en Perl" ou même sa version courte "perlipc".
Tout le monde peut alors taper la commande suivant :
perldoc perlipc
et lire de quoi vous voulez parler...
PS: dans les prochaines versions, je pense que je vais modifier les en-têtes de ce document pour que le titre du chapitre apparaisse sur chaque page.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Sun, 26 Mar 2006 19:06:05 +0200,
Asterbing <no@thanks.com> écrivait (wrote):
In article <r7zmjfsu1s.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
Lorsque vous citez "la" documenation, il vaut mieux citer le(s)
titre(s) en question (par exemple "perlfaq9", section "...xxx...")
Bien sûr. Cette documentation est une traduction française dont vous
avez écrit l'avant-propos, Paul : <http://perl.enstimac.fr/perl-all-fr-
pdf.pdf>. Le chapitre 45.2 pour être le plus large possible.
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours
pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45
s'appelle "perlport - écrire du code Perl portable", la section 45.2
"PROBLÈMES" !?!
Le 42.6.2 (précédement cité) parle bien d'un "client Webget" mais le
plus important c'est le titre du chapitre "perlipc - Communication
inter-processus en Perl" ou même sa version courte "perlipc".
Tout le monde peut alors taper la commande suivant :
perldoc perlipc
et lire de quoi vous voulez parler...
PS: dans les prochaines versions, je pense que je vais modifier les
en-têtes de ce document pour que le titre du chapitre apparaisse sur
chaque page.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Sun, 26 Mar 2006 19:06:05 +0200, Asterbing écrivait (wrote):
In article , says...
Lorsque vous citez "la" documenation, il vaut mieux citer le(s) titre(s) en question (par exemple "perlfaq9", section "...xxx...")
Bien sûr. Cette documentation est une traduction française dont vous avez écrit l'avant-propos, Paul : <http://perl.enstimac.fr/perl-all-fr- pdf.pdf>. Le chapitre 45.2 pour être le plus large possible.
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45 s'appelle "perlport - écrire du code Perl portable", la section 45.2 "PROBLÈMES" !?!
Le 42.6.2 (précédement cité) parle bien d'un "client Webget" mais le plus important c'est le titre du chapitre "perlipc - Communication inter-processus en Perl" ou même sa version courte "perlipc".
Tout le monde peut alors taper la commande suivant :
perldoc perlipc
et lire de quoi vous voulez parler...
PS: dans les prochaines versions, je pense que je vais modifier les en-têtes de ce document pour que le titre du chapitre apparaisse sur chaque page.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Asterbing
In article , says...
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45 s'appelle "perlport - écrire du code Perl portable", la section 45.2 "PROBLÈMES" !?!
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi effectivement vu perldoc perlipc, mais il me semble que cet aspect est désormais réglé, me reste à voir fork ou select/poll ; pas encore eu le temps et ceci n'est pas très clair pour moi pour l'instant.
In article <r7r74orzq3.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours
pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45
s'appelle "perlport - écrire du code Perl portable", la section 45.2
"PROBLÈMES" !?!
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du
chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi
effectivement vu perldoc perlipc, mais il me semble que cet aspect est
désormais réglé, me reste à voir fork ou select/poll ; pas encore eu le
temps et ceci n'est pas très clair pour moi pour l'instant.
Oui... Je m'en doutais un peu ! ;-) Mais vous ne nous dites toujours pas le titre du chapitre ni celui de la section.
Dans la version actuelle du document que vous citez, le chapitre 45 s'appelle "perlport - écrire du code Perl portable", la section 45.2 "PROBLÈMES" !?!
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi effectivement vu perldoc perlipc, mais il me semble que cet aspect est désormais réglé, me reste à voir fork ou select/poll ; pas encore eu le temps et ceci n'est pas très clair pour moi pour l'instant.
Paul Gaborit
À (at) Tue, 28 Mar 2006 10:58:35 +0200, Asterbing écrivait (wrote):
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi effectivement vu perldoc perlipc [...]
C'est promis, après cette réponse, j'arrête ! ;-)
« 42.5 Sockets: Communication Client/Serveur », c'est une *section* !
Le *chapitre*, c'est « 45 perlipc - Communication inter-processus en Perl[...] ».
C'est le *titre* du chapitre (pas le numéro qui est arbitraire) qui est important car ce titre permet de retrouver la documentation originale. Le titre de la section (et toujours pas son numéro) permet ensuite de se situer dans le documentation (originale ou non).
Je vais modifier les en-têtes et l'avant-propos de la compilation PDF pour que ce soit clair.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 28 Mar 2006 10:58:35 +0200,
Asterbing <no@thanks.com> écrivait (wrote):
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du
chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi
effectivement vu perldoc perlipc [...]
C'est promis, après cette réponse, j'arrête ! ;-)
« 42.5 Sockets: Communication Client/Serveur », c'est une *section* !
Le *chapitre*, c'est « 45 perlipc - Communication inter-processus en
Perl[...] ».
C'est le *titre* du chapitre (pas le numéro qui est arbitraire) qui
est important car ce titre permet de retrouver la documentation
originale. Le titre de la section (et toujours pas son numéro) permet
ensuite de se situer dans le documentation (originale ou non).
Je vais modifier les en-têtes et l'avant-propos de la compilation PDF
pour que ce soit clair.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 28 Mar 2006 10:58:35 +0200, Asterbing écrivait (wrote):
Bon, ce matin je suis moins speed et moins dyslexique : il s'agissait du chapitre "42.5 Sockets : Communication Client/Serveur". J'ai aussi effectivement vu perldoc perlipc [...]
C'est promis, après cette réponse, j'arrête ! ;-)
« 42.5 Sockets: Communication Client/Serveur », c'est une *section* !
Le *chapitre*, c'est « 45 perlipc - Communication inter-processus en Perl[...] ».
C'est le *titre* du chapitre (pas le numéro qui est arbitraire) qui est important car ce titre permet de retrouver la documentation originale. Le titre de la section (et toujours pas son numéro) permet ensuite de se situer dans le documentation (originale ou non).
Je vais modifier les en-têtes et l'avant-propos de la compilation PDF pour que ce soit clair.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Asterbing
In article <e06vs5$js0$, nicolas$ says...
die "fork: $!n" unless defined $child;
Bon, après quelques jours sur d'autres sujet, je reviens sur le gril.
Est-ce qu'un code comme ça est OK dans le cas d'un GET pour lequel je n'attends aucun retour utile ?
my $pid = fork(); die "fork: $!n" unless defined $pid; if (!$pid) { # processus fils StatsRelay(); exit 0; }
print "<p>Le process père fait d'autres choses sans relation avec le GET </p>";
sub StatsRelay{ print "<p>Un clone fils gère un GET non bloquant pour le père </p>";} ################################### FIN #############################
Bon, pour d'autres cas, un peu plus tard, j'aurais certainement à arrêter le process père si le StatsRelay() du fils échoue.
Le code du fils deviendrai donc : if (!$pid) { # processus fils $rc = StatsRelay(); if (!$rc) { # comment stopper le père si arrive ici ? } exit 0; }
In article <e06vs5$js0$1@biggoron.nerim.net>, nicolas$george@salle-s.org
says...
die "fork: $!n" unless defined $child;
Bon, après quelques jours sur d'autres sujet, je reviens sur le gril.
Est-ce qu'un code comme ça est OK dans le cas d'un GET pour lequel je
n'attends aucun retour utile ?
my $pid = fork();
die "fork: $!n" unless defined $pid;
if (!$pid)
{ # processus fils
StatsRelay();
exit 0;
}
print "<p>Le process père fait d'autres choses sans relation avec le GET
</p>";
sub StatsRelay{
print "<p>Un clone fils gère un GET non bloquant pour le père
</p>";}
################################### FIN #############################
Bon, pour d'autres cas, un peu plus tard, j'aurais certainement à
arrêter le process père si le StatsRelay() du fils échoue.
Le code du fils deviendrai donc :
if (!$pid)
{ # processus fils
$rc = StatsRelay();
if (!$rc)
{
# comment stopper le père si arrive ici ?
}
exit 0;
}
my $pid = fork(); die "fork: $!n" unless defined $pid; if (!$pid) { # processus fils StatsRelay(); exit 0; }
print "<p>Le process père fait d'autres choses sans relation avec le GET </p>";
sub StatsRelay{ print "<p>Un clone fils gère un GET non bloquant pour le père </p>";} ################################### FIN #############################
Bon, pour d'autres cas, un peu plus tard, j'aurais certainement à arrêter le process père si le StatsRelay() du fils échoue.
Le code du fils deviendrai donc : if (!$pid) { # processus fils $rc = StatsRelay(); if (!$rc) { # comment stopper le père si arrive ici ? } exit 0; }
Nicolas George
Asterbing wrote in message :
Est-ce qu'un code comme ça est OK dans le cas d'un GET pour lequel je n'attends aucun retour utile ?
Si le père se termine relativement rapidement après ça, c'est bon. S'il reste longtemps, il faut s'occuper des zombies.
Bon, pour d'autres cas, un peu plus tard, j'aurais certainement à arrêter le process père si le StatsRelay() du fils échoue.
Je ne comprends pas : si c'est pour attendre le résultat immédiatement, autant ne pas forker.
Asterbing wrote in message
<MPG.1e963cb71125512e9897b9@news.tiscali.fr>:
Est-ce qu'un code comme ça est OK dans le cas d'un GET pour lequel je
n'attends aucun retour utile ?
Si le père se termine relativement rapidement après ça, c'est bon. S'il
reste longtemps, il faut s'occuper des zombies.
Bon, pour d'autres cas, un peu plus tard, j'aurais certainement à
arrêter le process père si le StatsRelay() du fils échoue.
Je ne comprends pas : si c'est pour attendre le résultat immédiatement,
autant ne pas forker.
