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).
À (at) Fri, 24 Mar 2006 14:12:17 +0100, Asterbing écrivait (wrote):
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 ?
Lorsque vous citez "la" documenation, il vaut mieux citer le(s) titre(s) en question (par exemple "perlfaq9", section "...xxx...") plutôt qu'un numéro qui est purement spécifique à une compilation ou à un ouvrage donné et qui, de plus, peut varier d'une version à l'autre... La seule documentation officielle de Perl est celle qui est fournie avec les distributions et elle ne comporte pas de numérotation.
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).
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable. Vous pouvez le réduire en utilisant alarm() et eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du multi-process ou du multi-thread ou par un module qui le fait pour vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur CPAN).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 24 Mar 2006 14:12:17 +0100,
Asterbing <no@thanks.com> écrivait (wrote):
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 ?
Lorsque vous citez "la" documenation, il vaut mieux citer le(s)
titre(s) en question (par exemple "perlfaq9", section "...xxx...")
plutôt qu'un numéro qui est purement spécifique à une compilation ou à
un ouvrage donné et qui, de plus, peut varier d'une version à
l'autre... La seule documentation officielle de Perl est celle qui est
fournie avec les distributions et elle ne comporte pas de
numérotation.
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).
Le timeout de l'établissement d'une connexion est celui de la pile
TCP/IP de votre système. À ma connaissance, il n'est pas
paramètrable. Vous pouvez le réduire en utilisant alarm() et
eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du
multi-process ou du multi-thread ou par un module qui le fait pour
vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur
CPAN).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 24 Mar 2006 14:12:17 +0100, Asterbing écrivait (wrote):
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 ?
Lorsque vous citez "la" documenation, il vaut mieux citer le(s) titre(s) en question (par exemple "perlfaq9", section "...xxx...") plutôt qu'un numéro qui est purement spécifique à une compilation ou à un ouvrage donné et qui, de plus, peut varier d'une version à l'autre... La seule documentation officielle de Perl est celle qui est fournie avec les distributions et elle ne comporte pas de numérotation.
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).
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable. Vous pouvez le réduire en utilisant alarm() et eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du multi-process ou du multi-thread ou par un module qui le fait pour vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur CPAN).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
DoMinix
À (at) Fri, 24 Mar 2006 14:12:17 +0100, Asterbing écrivait (wrote): ...
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).
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...) il est possible de changer cette valeur, cependant attention : le changement sera global sur le systeme. Sous Windows une clef de registre permet si je me souvient bien se changement, mais la c'est un reboot qui faut pour l'activer :(
-- dominix
À (at) Fri, 24 Mar 2006 14:12:17 +0100,
Asterbing <no@thanks.com> écrivait (wrote):
...
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).
Le timeout de l'établissement d'une connexion est celui de la pile
TCP/IP de votre système. À ma connaissance, il n'est pas
paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...)
il est possible de changer cette valeur, cependant attention :
le changement sera global sur le systeme.
Sous Windows une clef de registre permet si je me souvient bien se
changement, mais la c'est un reboot qui faut pour l'activer :(
À (at) Fri, 24 Mar 2006 14:12:17 +0100, Asterbing écrivait (wrote): ...
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).
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...) il est possible de changer cette valeur, cependant attention : le changement sera global sur le systeme. Sous Windows une clef de registre permet si je me souvient bien se changement, mais la c'est un reboot qui faut pour l'activer :(
-- dominix
Asterbing
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.
Bon, je m'aperçois de plusieurs erreurs dans ma demande, dont : 1) La syntaxe même du sub est mauvaise (j'oublie le sub et l'absence de ()). Tout ceci avait été écrit un peu vite.
2) Je n'utilise pas vraiment IO::Socket. Serait-ce mieux ?
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable. Vous pouvez le réduire en utilisant alarm() et eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du multi-process ou du multi-thread ou par un module qui le fait pour vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur CPAN).
Oui, mais je dois utiliser ce qui est livré en standard avec tous les Perl 5.x (différent sur les différents serveurs) : donc, du pur Perl ou en s'appuyant sur le stock de modules livré par défaut (dont IO:Socket si j'ai tout compris).
Bon, je pose ma question différemment : comment écririez vous le sub StatsRelay le plus simplement, sans ajout de module (même pas sous /cgi- bin), pour que rien ne soit bloquant pour le reste du script et sans se soucier du retour (je rappelle que je me moque du retour, il s'agit juste de passer les parametres via l'url au cgi distant) ?
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.
Bon, je m'aperçois de plusieurs erreurs dans ma demande, dont :
1) La syntaxe même du sub est mauvaise (j'oublie le sub et l'absence de
()). Tout ceci avait été écrit un peu vite.
2) Je n'utilise pas vraiment IO::Socket. Serait-ce mieux ?
Le timeout de l'établissement d'une connexion est celui de la pile
TCP/IP de votre système. À ma connaissance, il n'est pas
paramètrable. Vous pouvez le réduire en utilisant alarm() et
eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du
multi-process ou du multi-thread ou par un module qui le fait pour
vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur
CPAN).
Oui, mais je dois utiliser ce qui est livré en standard avec tous les
Perl 5.x (différent sur les différents serveurs) : donc, du pur Perl ou
en s'appuyant sur le stock de modules livré par défaut (dont IO:Socket
si j'ai tout compris).
Bon, je pose ma question différemment : comment écririez vous le sub
StatsRelay le plus simplement, sans ajout de module (même pas sous /cgi-
bin), pour que rien ne soit bloquant pour le reste du script et sans se
soucier du retour (je rappelle que je me moque du retour, il s'agit
juste de passer les parametres via l'url au cgi distant) ?
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.
Bon, je m'aperçois de plusieurs erreurs dans ma demande, dont : 1) La syntaxe même du sub est mauvaise (j'oublie le sub et l'absence de ()). Tout ceci avait été écrit un peu vite.
2) Je n'utilise pas vraiment IO::Socket. Serait-ce mieux ?
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable. Vous pouvez le réduire en utilisant alarm() et eval{}. Pour le rendre non-bloquant, vous êtes obligé de passer par du multi-process ou du multi-thread ou par un module qui le fait pour vous (par exemple les modules Parallel::* ou LWP::Parallel::* sur CPAN).
Oui, mais je dois utiliser ce qui est livré en standard avec tous les Perl 5.x (différent sur les différents serveurs) : donc, du pur Perl ou en s'appuyant sur le stock de modules livré par défaut (dont IO:Socket si j'ai tout compris).
Bon, je pose ma question différemment : comment écririez vous le sub StatsRelay le plus simplement, sans ajout de module (même pas sous /cgi- bin), pour que rien ne soit bloquant pour le reste du script et sans se soucier du retour (je rappelle que je me moque du retour, il s'agit juste de passer les parametres via l'url au cgi distant) ?
Asterbing
In article <442631e6$0$31428$, says...
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...) il est possible de changer cette valeur, cependant attention : le changement sera global sur le systeme. Sous Windows une clef de registre permet si je me souvient bien se changement, mais la c'est un reboot qui faut pour l'activer :(
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez indulgents) de l'alarme pour interrompre l'appel d'emblée au bout d'un certain temps et celle d'une sorte de multi-threading à la mode Perl... Mais comment donc ?
Comme dit en réponse à Paul G. juste avant, Dominix, je pose ma question différemment pour éviter d'être noyé de détails que je ne saisi pas encore avec mes trois semaines de Perl derrière moi (et que je n'ai pas spécialement choisi comme vous l'aurez compris, enfin, pas si vite) : comment écririez vous le sub StatsRelay le plus simplement, sans ajout de module (même pas sous /cgi-bin), pour que rien ne soit bloquant pour le reste du script et sans se soucier du retour (je rappelle que je me moque du retour, il s'agit juste de passer les parametres via l'url au cgi distant) ?
Merci de votre assistance
In article <442631e6$0$31428$626a54ce@news.free.fr>, dominix@iquebec.com
says...
Le timeout de l'établissement d'une connexion est celui de la pile
TCP/IP de votre système. À ma connaissance, il n'est pas
paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...)
il est possible de changer cette valeur, cependant attention :
le changement sera global sur le systeme.
Sous Windows une clef de registre permet si je me souvient bien se
changement, mais la c'est un reboot qui faut pour l'activer :(
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste
l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez
indulgents) de l'alarme pour interrompre l'appel d'emblée au bout d'un
certain temps et celle d'une sorte de multi-threading à la mode Perl...
Mais comment donc ?
Comme dit en réponse à Paul G. juste avant, Dominix, je pose ma question
différemment pour éviter d'être noyé de détails que je ne saisi pas
encore avec mes trois semaines de Perl derrière moi (et que je n'ai pas
spécialement choisi comme vous l'aurez compris, enfin, pas si vite) :
comment écririez vous le sub StatsRelay le plus simplement, sans ajout
de module (même pas sous /cgi-bin), pour que rien ne soit bloquant pour
le reste du script et sans se soucier du retour (je rappelle que je me
moque du retour, il s'agit juste de passer les parametres via l'url au
cgi distant) ?
Le timeout de l'établissement d'une connexion est celui de la pile TCP/IP de votre système. À ma connaissance, il n'est pas paramètrable.
Sur les systemes supportant la commande sysctl (linux, *bsd ...) il est possible de changer cette valeur, cependant attention : le changement sera global sur le systeme. Sous Windows une clef de registre permet si je me souvient bien se changement, mais la c'est un reboot qui faut pour l'activer :(
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez indulgents) de l'alarme pour interrompre l'appel d'emblée au bout d'un certain temps et celle d'une sorte de multi-threading à la mode Perl... Mais comment donc ?
Comme dit en réponse à Paul G. juste avant, Dominix, je pose ma question différemment pour éviter d'être noyé de détails que je ne saisi pas encore avec mes trois semaines de Perl derrière moi (et que je n'ai pas spécialement choisi comme vous l'aurez compris, enfin, pas si vite) : comment écririez vous le sub StatsRelay le plus simplement, sans ajout de module (même pas sous /cgi-bin), pour que rien ne soit bloquant pour le reste du script et sans se soucier du retour (je rappelle que je me moque du retour, il s'agit juste de passer les parametres via l'url au cgi distant) ?
Merci de votre assistance
Asterbing
In article , says...
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 ?
Bon, voici l'état des lieux de la fonction :
StatsRelay() { use IO::Socket;
my $host = "www.domain.com"; my $path = "/cgi-bin/stats.cgi?a=2&t&z'&rz2"; my $port = 8080;
if ($host eq "" or $path eq ""){return(0);} my $iadr = inet_aton($host) || return(0); my $padr = sockaddr_in($port, $iadr); my $proto = getprotobyname('tcp');
socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0); if(!connect(hpSOCK, $padr)){return(0);} # ou my $sock = IO::Socket::INET->new( "$host:$port" ) ;
# ici, je note l'appel dans un fichier local # aucun traitement relatif au retour du GET
close(hpSOCK); return(1); }
Que j'appelle simplement via "$success = StatsRelay();" et encore, je pourrais me passer de récupérer le retour dans la mesure où cet appel sera effectué plusieurs fois par heure alors que quelques points de mesure par jour sont utiles seulement : une sécurité si le serveur distant n'est pas dispo sur une tranche horaire.
Comment faire que ce sub ou un autre réalisant le même objectif (passer des parametre via url à un script distant), par con contenu ou le mode d'appel, ne soit pas bloquant pour le reste du script ?
In article <MPG.1e8e0e9f7e1f697e98979f@news.tiscali.fr>, no@thanks.com
says...
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 ?
Bon, voici l'état des lieux de la fonction :
StatsRelay()
{
use IO::Socket;
my $host = "www.domain.com";
my $path = "/cgi-bin/stats.cgi?a=2&t&z'&rz2";
my $port = 8080;
if ($host eq "" or $path eq ""){return(0);}
my $iadr = inet_aton($host) || return(0);
my $padr = sockaddr_in($port, $iadr);
my $proto = getprotobyname('tcp');
socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0);
if(!connect(hpSOCK, $padr)){return(0);}
# ou my $sock = IO::Socket::INET->new( "$host:$port" ) ;
# ici, je note l'appel dans un fichier local
# aucun traitement relatif au retour du GET
close(hpSOCK);
return(1);
}
Que j'appelle simplement via "$success = StatsRelay();" et encore, je
pourrais me passer de récupérer le retour dans la mesure où cet appel
sera effectué plusieurs fois par heure alors que quelques points de
mesure par jour sont utiles seulement : une sécurité si le serveur
distant n'est pas dispo sur une tranche horaire.
Comment faire que ce sub ou un autre réalisant le même objectif (passer
des parametre via url à un script distant), par con contenu ou le mode
d'appel, ne soit pas bloquant pour le reste du script ?
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 ?
Bon, voici l'état des lieux de la fonction :
StatsRelay() { use IO::Socket;
my $host = "www.domain.com"; my $path = "/cgi-bin/stats.cgi?a=2&t&z'&rz2"; my $port = 8080;
if ($host eq "" or $path eq ""){return(0);} my $iadr = inet_aton($host) || return(0); my $padr = sockaddr_in($port, $iadr); my $proto = getprotobyname('tcp');
socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0); if(!connect(hpSOCK, $padr)){return(0);} # ou my $sock = IO::Socket::INET->new( "$host:$port" ) ;
# ici, je note l'appel dans un fichier local # aucun traitement relatif au retour du GET
close(hpSOCK); return(1); }
Que j'appelle simplement via "$success = StatsRelay();" et encore, je pourrais me passer de récupérer le retour dans la mesure où cet appel sera effectué plusieurs fois par heure alors que quelques points de mesure par jour sont utiles seulement : une sécurité si le serveur distant n'est pas dispo sur une tranche horaire.
Comment faire que ce sub ou un autre réalisant le même objectif (passer des parametre via url à un script distant), par con contenu ou le mode d'appel, ne soit pas bloquant pour le reste du script ?
Asterbing
In article , says...
StatsRelay() {
Décidément :( Lisez :
sub StatsRelay {
merci
In article <MPG.1e90eceef3159ce59897a7@news.tiscali.fr>, no@thanks.com
says...
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez indulgents) de l'alarme pour interrompre l'appel
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.
d'une sorte de multi-threading à la mode Perl...
Puisque le retour est uniquement une valeur succès / échec, un fork ferait très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une connexion, on passe la socket en non-bloquant avant le connect, on fait le connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en pratique ça se fait bien. Attention : la résolution DNS est toujours bloquante dans ce cas.
Asterbing wrote in message
<MPG.1e90e9f0eb0b96fe9897a6@news.tiscali.fr>:
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste
l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez
indulgents) de l'alarme pour interrompre l'appel
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.
d'une sorte de multi-threading à la mode Perl...
Puisque le retour est uniquement une valeur succès / échec, un fork ferait
très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du
fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des
timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une
connexion, on passe la socket en non-bloquant avant le connect, on fait le
connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et
quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la
connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en
pratique ça se fait bien. Attention : la résolution DNS est toujours
bloquante dans ce cas.
Bon, on laisse tombver l'idée d'un timeout personnalisable donc. Reste l'idée (je répète ce qui m'a été dit, sans encore bien savoir, soyez indulgents) de l'alarme pour interrompre l'appel
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.
d'une sorte de multi-threading à la mode Perl...
Puisque le retour est uniquement une valeur succès / échec, un fork ferait très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une connexion, on passe la socket en non-bloquant avant le connect, on fait le connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en pratique ça se fait bien. Attention : la résolution DNS est toujours bloquante dans ce cas.
Asterbing
In article <e06l1e$g16$, nicolas$ says...
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée, le comportement est hautement non-portable ...
OK, j'abandonne cette voie.
Puisque le retour est uniquement une valeur succès / échec
Exact et encore je pourrais même m'en passer si ça amenait à une solution encore plus *simple*.
, un fork ferait
très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une connexion, on passe la socket en non-bloquant avant le connect, on fait le connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en pratique ça se fait bien. Attention : la résolution DNS est toujours bloquante dans ce cas.
Bon, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers des urls ou partie de doc avec exemples ?
In article <e06l1e$g16$1@biggoron.nerim.net>, nicolas$george@salle-s.org
says...
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée,
le comportement est hautement non-portable ...
OK, j'abandonne cette voie.
Puisque le retour est uniquement une valeur succès / échec
Exact et encore je pourrais même m'en passer si ça amenait à une
solution encore plus *simple*.
, un fork ferait
très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du
fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des
timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une
connexion, on passe la socket en non-bloquant avant le connect, on fait le
connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et
quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la
connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en
pratique ça se fait bien. Attention : la résolution DNS est toujours
bloquante dans ce cas.
Bon, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la
solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers
des urls ou partie de doc avec exemples ?
Les signaux pour implémenter des timeouts, ce n'est jamais une bonne idée, le comportement est hautement non-portable ...
OK, j'abandonne cette voie.
Puisque le retour est uniquement une valeur succès / échec
Exact et encore je pourrais même m'en passer si ça amenait à une solution encore plus *simple*.
, un fork ferait
très bien l'affaire. Éventuellement, un pipe pour être notifié de la mort du fils par autre chose qu'un signal.
Une autre solution est de multiplexer (avec select / poll, qui ont des timeouts incorporés) la connexion. Pour multiplexer l'établissement d'une connexion, on passe la socket en non-bloquant avant le connect, on fait le connect qui échoue avec EINPROGRESS, on surveille la socket en écriture, et quand elle est écrivable, on utilise getsockopt / SO_ERROR pour savoir si la connexion a réussi ou pas. Ça a l'air un peu technique dit comme ça, mais en pratique ça se fait bien. Attention : la résolution DNS est toujours bloquante dans ce cas.
Bon, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers des urls ou partie de doc avec exemples ?
Asterbing
In article <e06l1e$g16$, nicolas$ says...
Attention : la résolution DNS est toujours bloquante dans ce cas.
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
In article <e06l1e$g16$1@biggoron.nerim.net>, nicolas$george@salle-s.org
says...
Attention : la résolution DNS est toujours
bloquante dans ce cas.
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
Attention : la résolution DNS est toujours bloquante dans ce cas.
Mince, pas moyen de contourner ça, sans passer une adresse IP direct ?
Nicolas George
Asterbing wrote in message :
Exact et encore je pourrais même m'en passer si ça amenait à une solution encore plus *simple*.
Pour le coup, ça devient complètement trivial : il suffit de mettre au début de la fonction quelque chose comme :
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, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers des urls ou partie de doc avec exemples ?
C'est plus un problème de programmation système que de Perl lui-même. Dans ce cas, la référence canonique, c'est _Advanced Programming in the Unix Environment_ et/ou _Unix Network Programming_. Je ne crois pas qu'ils soient disponibles en ligne.
Asterbing wrote in message
<MPG.1e9100af93db67fd9897a9@news.tiscali.fr>:
Exact et encore je pourrais même m'en passer si ça amenait à une
solution encore plus *simple*.
Pour le coup, ça devient complètement trivial : il suffit de mettre au début
de la fonction quelque chose comme :
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, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la
solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers
des urls ou partie de doc avec exemples ?
C'est plus un problème de programmation système que de Perl lui-même. Dans
ce cas, la référence canonique, c'est _Advanced Programming in the Unix
Environment_ et/ou _Unix Network Programming_. Je ne crois pas qu'ils soient
disponibles en ligne.
Exact et encore je pourrais même m'en passer si ça amenait à une solution encore plus *simple*.
Pour le coup, ça devient complètement trivial : il suffit de mettre au début de la fonction quelque chose comme :
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, fork, pipe ou select/poll : moi, je suis d'accord :) Quelle est la solution la plus facile à mettre en oeuvre ? Pourrais-tu m'envoyer vers des urls ou partie de doc avec exemples ?
C'est plus un problème de programmation système que de Perl lui-même. Dans ce cas, la référence canonique, c'est _Advanced Programming in the Unix Environment_ et/ou _Unix Network Programming_. Je ne crois pas qu'ils soient disponibles en ligne.
