retour de la fonction select() et zéro caractères dispo ...
6 réponses
Eric Bart
Bonjour,
sous linux j'utilise select() pour la réception sur
un pipe. Tout se passe bien jusqu'à ce que l'autre
programme ferme son pipe en écriture. Alors select()
se déclenche infiniment sans qu'il y ait de caractère
dispo !!??
Why ?
Si je ferme alors le pipe en lecture pour le rouvrir aussitôt,
tout redevient normal.
Quel newsgroup anglais (ou français) serait le mieux adapté
pour cette question ?
----PRG1---------
Ouverture du pipe en lecture :
// without O_NONBLOCK, the program blocks until the pipe write end is open
iAgiPipeFD = open(sPipeFileName.c_str(), O_RDONLY|O_NONBLOCK);
----PRG2--------------
Ouverture du pipe en écriture :
iWriteFifo = open(sTmp.c_str(), O_WRONLY);
Ligne créant une infinité de select() nul :
if ( close(iWriteFifo) == -1)
------------------
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
DINH Viêt Hoà
Bonjour,
sous linux j'utilise select() pour la réception sur un pipe. Tout se passe bien jusqu'à ce que l'autre programme ferme son pipe en écriture. Alors select() se déclenche infiniment sans qu'il y ait de caractère dispo !!??
Why ?
Si je ferme alors le pipe en lecture pour le rouvrir aussitôt, tout redevient normal.
quand tu lis zéro caractères, c'est que le flux distant a été fermé. Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé. Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro caractères.
sous linux j'utilise select() pour la réception sur
un pipe. Tout se passe bien jusqu'à ce que l'autre
programme ferme son pipe en écriture. Alors select()
se déclenche infiniment sans qu'il y ait de caractère
dispo !!??
Why ?
Si je ferme alors le pipe en lecture pour le rouvrir aussitôt,
tout redevient normal.
quand tu lis zéro caractères, c'est que le flux distant a été fermé.
Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé.
Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro
caractères.
sous linux j'utilise select() pour la réception sur un pipe. Tout se passe bien jusqu'à ce que l'autre programme ferme son pipe en écriture. Alors select() se déclenche infiniment sans qu'il y ait de caractère dispo !!??
Why ?
Si je ferme alors le pipe en lecture pour le rouvrir aussitôt, tout redevient normal.
quand tu lis zéro caractères, c'est que le flux distant a été fermé. Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé. Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro caractères.
quand tu lis zéro caractères, c'est que le flux distant a été fermé. Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé. Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro caractères.
Merci. Je voulais utiliser ce "named pipe" en lecture pour plusieurs pipe en écriture, comme une sorte de serveur. A chaque fois que le pipe en lecture reçoit, il sait quel pipe ouvrir et utiliser pour répondre. C'est pour ça que je voulais laisser le pipe en lecture toujours ouvert.
D'après ce que vous me dites, je me demande s'il est possible d'envisager plusieurs ouvertures d'un pipe en écriture vers un pipe en lecture ouvert une seule fois ...
Devrais-je plutôt utiliser des sockets ? L'inconvénient des sockets est qu'on ne sait pas forcément si le port souhaité est innutilisé par le système. Est-ce différent avec les sockets unix ?
Ouf ! Merci
quand tu lis zéro caractères, c'est que le flux distant a été fermé.
Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé.
Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro
caractères.
Merci. Je voulais utiliser ce "named pipe" en lecture pour plusieurs
pipe en écriture, comme une sorte de serveur. A chaque fois que le
pipe en lecture reçoit, il sait quel pipe ouvrir et utiliser pour
répondre. C'est pour ça que je voulais laisser le pipe en lecture
toujours ouvert.
D'après ce que vous me dites, je me demande s'il est possible d'envisager
plusieurs ouvertures d'un pipe en écriture vers un pipe en lecture ouvert
une seule fois ...
Devrais-je plutôt utiliser des sockets ?
L'inconvénient des sockets est qu'on ne sait pas forcément si le port
souhaité est innutilisé par le système. Est-ce différent avec les sockets unix ?
quand tu lis zéro caractères, c'est que le flux distant a été fermé. Dans ton cas, il s'agit du côté écriture du pipe qui a été fermé. Tu sais qu'il faut fermer le côté lecture lorsque tu lis zéro caractères.
Merci. Je voulais utiliser ce "named pipe" en lecture pour plusieurs pipe en écriture, comme une sorte de serveur. A chaque fois que le pipe en lecture reçoit, il sait quel pipe ouvrir et utiliser pour répondre. C'est pour ça que je voulais laisser le pipe en lecture toujours ouvert.
D'après ce que vous me dites, je me demande s'il est possible d'envisager plusieurs ouvertures d'un pipe en écriture vers un pipe en lecture ouvert une seule fois ...
Devrais-je plutôt utiliser des sockets ? L'inconvénient des sockets est qu'on ne sait pas forcément si le port souhaité est innutilisé par le système. Est-ce différent avec les sockets unix ?
Ouf ! Merci
Laurent Wacrenier
Eric Bart écrit:
L'inconvénient des sockets est qu'on ne sait pas forcément si le port souhaité est innutilisé par le système.
Avec les socket IP, on peut binder sur un port aléatoire.
Est-ce différent avec les sockets unix ?
Pour les socket unix, la ressource qui les identifie sur le système est un fichier. On peut aussi ouvrir des socket anonymes avec socketpair().
Si l'application reste sur une même machine, il faut utiliser les socket unix.
Eric Bart <eb-adm@eric-bart.pasdepubmerci.net> écrit:
L'inconvénient des sockets est qu'on ne sait pas forcément si le port
souhaité est innutilisé par le système.
Avec les socket IP, on peut binder sur un port aléatoire.
Est-ce différent avec les sockets unix ?
Pour les socket unix, la ressource qui les identifie sur le système
est un fichier. On peut aussi ouvrir des socket anonymes avec
socketpair().
Si l'application reste sur une même machine, il faut utiliser les
socket unix.
"Laurent Wacrenier" <lwa@ teaser . fr> wrote in message news:
Eric Bart écrit:
L'inconvénient des sockets est qu'on ne sait pas forcément si le port souhaité est innutilisé par le système.
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ? Ce port serveur ne doit pas non plus être en conflit avec un autre serveur.
Est-ce différent avec les sockets unix ?
Pour les socket unix, la ressource qui les identifie sur le système est un fichier. On peut aussi ouvrir des socket anonymes avec socketpair().
Si l'application reste sur une même machine, il faut utiliser les socket unix.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent sur la même machine. Merci de me dire quelle est la commande qui permet de créer des sockets unix compatibles entre eux pour chaque programme sans avoir à définir à l'avance de port réservé.
"Laurent Wacrenier" <lwa@ teaser . fr> wrote in message news:slrncdr0jg.jqt.lwa@victor.teaser.fr...
Eric Bart <eb-adm@eric-bart.pasdepubmerci.net> écrit:
L'inconvénient des sockets est qu'on ne sait pas forcément si le port
souhaité est innutilisé par le système.
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ? Ce port serveur
ne doit pas non plus être en conflit avec un autre serveur.
Est-ce différent avec les sockets unix ?
Pour les socket unix, la ressource qui les identifie sur le système
est un fichier. On peut aussi ouvrir des socket anonymes avec
socketpair().
Si l'application reste sur une même machine, il faut utiliser les
socket unix.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent
sur la même machine. Merci de me dire quelle est la commande qui
permet de créer des sockets unix compatibles entre eux pour chaque
programme sans avoir à définir à l'avance de port réservé.
"Laurent Wacrenier" <lwa@ teaser . fr> wrote in message news:
Eric Bart écrit:
L'inconvénient des sockets est qu'on ne sait pas forcément si le port souhaité est innutilisé par le système.
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ? Ce port serveur ne doit pas non plus être en conflit avec un autre serveur.
Est-ce différent avec les sockets unix ?
Pour les socket unix, la ressource qui les identifie sur le système est un fichier. On peut aussi ouvrir des socket anonymes avec socketpair().
Si l'application reste sur une même machine, il faut utiliser les socket unix.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent sur la même machine. Merci de me dire quelle est la commande qui permet de créer des sockets unix compatibles entre eux pour chaque programme sans avoir à définir à l'avance de port réservé.
Laurent Wacrenier
Eric Bart écrit:
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ?
Le serveur le connait. Il peut être transmis au client par un mécanisme hors bande (à la main, par exemple ou par une socket de contrôle comme le fait FTP)
Ce port serveur ne doit pas non plus être en conflit avec un autre serveur.
C'est comme ça que ça marche.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent sur la même machine. Merci de me dire quelle est la commande qui permet de créer des sockets unix compatibles entre eux pour chaque programme sans avoir à définir à l'avance de port réservé.
Il n'y a pas de port pour les sockets unix, mais éventuelement un chemin du système de fichier. Passer ça à bind() ou à connect() dans une struct sockaddr_un. Pour des sockets unix sans nom, utiliser socketpair().
Eric Bart <eb-adm@eric-bart.pasdepubmerci.net> écrit:
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ?
Le serveur le connait. Il peut être transmis au client par un
mécanisme hors bande (à la main, par exemple ou par une socket de
contrôle comme le fait FTP)
Ce port serveur
ne doit pas non plus être en conflit avec un autre serveur.
C'est comme ça que ça marche.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent
sur la même machine. Merci de me dire quelle est la commande qui
permet de créer des sockets unix compatibles entre eux pour chaque
programme sans avoir à définir à l'avance de port réservé.
Il n'y a pas de port pour les sockets unix, mais éventuelement un
chemin du système de fichier. Passer ça à bind() ou à connect() dans
une struct sockaddr_un. Pour des sockets unix sans nom, utiliser
socketpair().
Avec les socket IP, on peut binder sur un port aléatoire.
Mais il faut quand même connaitre le port du serveur, non ?
Le serveur le connait. Il peut être transmis au client par un mécanisme hors bande (à la main, par exemple ou par une socket de contrôle comme le fait FTP)
Ce port serveur ne doit pas non plus être en conflit avec un autre serveur.
C'est comme ça que ça marche.
Oui. Il s'agit d'un prg serveur et de plusieurs clients qui tournent sur la même machine. Merci de me dire quelle est la commande qui permet de créer des sockets unix compatibles entre eux pour chaque programme sans avoir à définir à l'avance de port réservé.
Il n'y a pas de port pour les sockets unix, mais éventuelement un chemin du système de fichier. Passer ça à bind() ou à connect() dans une struct sockaddr_un. Pour des sockets unix sans nom, utiliser socketpair().
