IO::Select ou select() perde le nord, utilisation forcée de alarm()
1 réponse
José
Bonjour,
Lors de l'utilisation de IO:Select je me suis aperçu que ce dernier
ne trouvait, à lire, plus de données sur le $socket alors que
ce n'est pas le cas.
La preuve, quand alarm() ou <$socket> sont remplacés par
le couple select()/read() de Perl tout baigne comme prévu.
Plutôt qu'un grand exposé, j'ai pris soin de créer 4
cas de fonctionnement de mon programme pour vous montrer le
comportement, qui me semble anormal, de IO:select (ou select...) .
Pour cela il faut lancer le programme comme précisé dans l'entête
du code source disponible ici : http://codepad.org/I8AICMTJ
Vous l'aurez compris, je suis à la recherche d'un témoignage ou
critique qui pourrait expliquer pourquoi IO::Select ou select
ne fonctionnent pas comme leurs version en C.
La seule piste que j'ai est que la lecture avec read, après un
IO::Select, désynchroniserait le pointeur (seek) sur le $socket.
Créant un retard de l'un par rapport à l'autre...
Merci pour m'avoir lu :)
PS: perso, j'aimerais utiliser IO::Select que alarm() d'où ma demande
d'aide!
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
Nicolas George
José , dans le message <4fa00f65$0$1713$, a écrit :
Lors de l'utilisation de IO:Select je me suis aperçu que ce dernier ne trouvait, à lire, plus de données sur le $socket alors que ce n'est pas le cas.
La seule piste que j'ai est que la lecture avec read, après un IO::Select, désynchroniserait le pointeur (seek) sur le $socket.
Tu n'es pas loin, mais parler de seek pour une socket n'a pas de sens.
Ton problème est que socket interroge la socket vue du point de vue du système d'exploitation, alors que read, que tu utilises, interroge le filehandle vu du point de vue de perl. Entre la socket et le filehandle, il y a tout le mécanisme de buffering de perl. S'il y a des données dans le buffer, elles sont déjà lues du point de vue de l'OS, mais pas de perl.
Il faut utiliser sysread avec les sockets si on veut faire du non-bloquant.
José , dans le message <4fa00f65$0$1713$426a74cc@news.free.fr>, a
écrit :
Lors de l'utilisation de IO:Select je me suis aperçu que ce dernier
ne trouvait, à lire, plus de données sur le $socket alors que
ce n'est pas le cas.
La seule piste que j'ai est que la lecture avec read, après un
IO::Select, désynchroniserait le pointeur (seek) sur le $socket.
Tu n'es pas loin, mais parler de seek pour une socket n'a pas de sens.
Ton problème est que socket interroge la socket vue du point de vue du
système d'exploitation, alors que read, que tu utilises, interroge le
filehandle vu du point de vue de perl. Entre la socket et le filehandle, il
y a tout le mécanisme de buffering de perl. S'il y a des données dans le
buffer, elles sont déjà lues du point de vue de l'OS, mais pas de perl.
Il faut utiliser sysread avec les sockets si on veut faire du non-bloquant.
José , dans le message <4fa00f65$0$1713$, a écrit :
Lors de l'utilisation de IO:Select je me suis aperçu que ce dernier ne trouvait, à lire, plus de données sur le $socket alors que ce n'est pas le cas.
La seule piste que j'ai est que la lecture avec read, après un IO::Select, désynchroniserait le pointeur (seek) sur le $socket.
Tu n'es pas loin, mais parler de seek pour une socket n'a pas de sens.
Ton problème est que socket interroge la socket vue du point de vue du système d'exploitation, alors que read, que tu utilises, interroge le filehandle vu du point de vue de perl. Entre la socket et le filehandle, il y a tout le mécanisme de buffering de perl. S'il y a des données dans le buffer, elles sont déjà lues du point de vue de l'OS, mais pas de perl.
Il faut utiliser sysread avec les sockets si on veut faire du non-bloquant.
