Bonjour,
j’aimerais savoir s’il existe en c quelquechose qui me permettrait d’envoyer une sortie
à l’entrée d’un autre programme un peu comme le | du shell.
man pipe 
[quote=“MisterFreez”]man pipe [/quote]Putain!
J’aurais eu une poutre dans l’œil que je n’aurais même pas vu?
merci.
Salut,
my two cents (si je me souviens bien des mes cours de système d’exploitation ):
- Un pipe ne qu’une seule fonction, lire ou écrire, pas les deux.
- On peut écrire 4ko max dans un pipe.
- le read() est “bloquant”.
++
On peut s’en servir dans les deux sens mais c’est pas recomandé, autant utiliser deux pipes ou un socket.
Jamais fais le test je le ferais ce soir.
Que veut-tu dire ?
read() travail sur des descripteurs de fichier donc sont fonctionnement ne change pas que ce soit un fichier, un pipe ou quoi que ce soit d’autre. Surtout que le noyau utilise un système de cache qui rend l’écriture instantanée (on attends pas la fin de l’écriture à l’endroit voulu mais dans le cache), ça lui permet d’optimiser ses sorties.
En effet, ce n’est pas recommandé… La norme POSIX impose cela d’ailleurs il me semble
En fait, tu peux écrire plus de 4ko, mais ce que je voulais dire, c’est que le “tube” ne peut pas prendre plus de 4ko à la fois.
[quote]Que veut-tu dire ?
read() travail sur des descripteurs de fichier donc sont fonctionnement ne change pas que ce soit un fichier, un pipe ou quoi que ce soit d’autre. Surtout que le noyau utilise un système de cache qui rend l’écriture instantanée (on attends pas la fin de l’écriture à l’endroit voulu mais dans le cache), ça lui permet d’optimiser ses sorties.[/quote]
Je me suis mal exprimé… Je voulais dire que si une partie de ton programme fait un read() sur un pipe et que “personne” ne vient jamais écrire dessus, le read() va se bloquer en attendant que quelqu’un écrive dessus… Enfin, si mes souvenirs sont bons
En fait, tu peux écrire plus de 4ko, mais ce que je voulais dire, c’est que le “tube” ne peut pas prendre plus de 4ko à la fois.[/quote]
C’est ce que je voulais vérifier.
[quote=“pyknite”][quote=“MisterFreez”]Que veut-tu dire ?
read() travail sur des descripteurs de fichier donc sont fonctionnement ne change pas que ce soit un fichier, un pipe ou quoi que ce soit d’autre. Surtout que le noyau utilise un système de cache qui rend l’écriture instantanée (on attends pas la fin de l’écriture à l’endroit voulu mais dans le cache), ça lui permet d’optimiser ses sorties.[/quote]
Je me suis mal exprimé… Je voulais dire que si une partie de ton programme fait un read() sur un pipe et que “personne” ne vient jamais écrire dessus, le read() va se bloquer en attendant que quelqu’un écrive dessus… Enfin, si mes souvenirs sont bons [/quote]
Et moi je suis un boulet qui lit write() alors qu’il y a écris read(). Donc oui l’appel à read() est bloquant dans tout les cas. Quand on fait un accès à un fichier, si le fichier ne se trouve pas en cache. Il y a une interruption (le processus deviens “en attente”) et le programme ne reprend la main (en fait il est déclaré “prêt”, c’est à l’ordonnanceur de décider) que lorsque le noyau à réellement effectué la lecture et que les données sont disponibles.
[quote=“MisterFreez”]
Et moi je suis un boulet qui lit write() alors qu’il y a écris read(). Donc oui l’appel à read() est bloquant dans tout les cas. Quand on fait un accès à un fichier, si le fichier ne se trouve pas en cache. Il y a une interruption (le processus deviens “en attente”) et le programme ne reprend la main (en fait il est déclaré “prêt”, c’est à l’ordonnanceur de décider) que lorsque le noyau à réellement effectué la lecture et que les données sont disponibles.[/quote]
Et si on veut pousser le bouchon encore un peu plus loin, on pourra dire qu’entre temps le processeur est passé en mode “noyau” (pour effectuer les appels systèmes) et qu’il est revenu en mode “utilisateur” lorsqu’il a redonné la main au thread (enfin, plutôt processus, ça dépend du contexte)
C’est ce que j’appelle de la discussion de haut vol 
Z’en avez de la chance!! M’enfin vous avez étudier pour aussi 
:smt003 :smt003 :smt003 :smt003
[quote=“M3t4linux”]C’est ce que j’appelle de la discussion de haut vol
Z’en avez de la chance!! M’enfin vous avez étudier pour aussi [/quote]
Correction, pour ma part, c’est “vous étudiés pour”, m’enfin, vous ne pouviez pas le savoir
ps: et d’ailleurs quand je disait “si je me souviens bien des mes cours de système d’exploitation”, il s’agissait des cours que j’ai suivi il y une ou deux semaines
Tu suis quelle formation et où ? Moi je suis en première année de master informatique à Grenoble.
Pour ce qui est des cours de système que j’ai eu. J’en ai eu pendant 2 ans à l’IUT d’Aix-en-Provence, puis un semestre l’an dernier en licence et enfin ce semestre.
Après 3 ans de formations, il serait décevant de ne pas avoir un minimum de connaissance sur le sujet.
[quote=“MisterFreez”]Tu suis quelle formation et où ? Moi je suis en première année de master informatique à Grenoble.
Pour ce qui est des cours de système que j’ai eu. J’en ai eu pendant 2 ans à l’IUT d’Aix-en-Provence, puis un semestre l’an dernier en licence et enfin ce semestre.
Après 3 ans de formations, il serait décevant de ne pas avoir un minimum de connaissance sur le sujet.[/quote]
Hum, je fais ingénieur en génie logiciel à Yverdon (CH) (eh oui, un ptit Suisse )…
La je suis en 3ème, et master l’année prochaine
Comme je fais ce que je dis et que je dis ce que je fais j’ai fais le test.
[code]#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
int main (int argc, char ** argv){
int tube[2];
int taille = 0;
long long unsigned buff = 0;
int val = 0;
pipe(tube);
errno = 0;
do{
val = write(tube[1], &buff, sizeof(buff));
if(-1 == val){
printf(“Une erreur s’est produite.\n”);
printf(“Voici le code de l’erreur : %d.\n”, errno);
printf(“Voici le nom de l’erreur : %d.\n”, strerror(errno));
break;
}
taille += val;
} while(taille < 4096 && val != 0);
if(taille < 4096){
printf(“On à écris plus de 4ko dans le pipe.\n”);
}
else{
printf(“Voici la quantité de donnée que l’on a écrit dans le pipe : %do\n”,
taille);
}
close(tube[0]);
close(tube[1]);
return 0;
} /* end of main() */[/code]
À l’exécution le résultat est invariable :
Ça signifie que la limite est à 4ko mais que write() ne renvoie pas d’erreur.
Normal, tu fais pas de read()
C’est pas bien de trafiquer mes écris 
bonjour à tous,
Je n’ai pas de diplôme d’informatique, j’espère ne pas trop dire de bêtises.
Vous parlez de tubes ordinaires: man pipe mais il y a aussi les tubes nommés: man mkfifo…
Il me semble que les tubes peuvent être rendus non bloquant avec fcntl: man fcntl (O_NONBLOCK, O_NDELAY …).
Je trouve plus facile d’utiliser pour la communication entre processus les files de messages:
System V: msg… (man msgget) ou POSIX mq_… (man 7 mq_overview).
qu’en pensez vous ?
(it’s raining man , alleluia 
)
[quote=“Dixippe”]bonjour à tous,
Je n’ai pas de diplôme d’informatique, j’espère ne pas trop dire de bêtises.
Vous parlez de tubes ordinaires: man pipe mais il y a aussi les tubes nommés: man mkfifo…
Il me semble que les tubes peuvent être rendus non bloquant avec fcntl: man fcntl (O_NONBLOCK, O_NDELAY …).
Je trouve plus facile d’utiliser pour la communication entre processus les files de messages:
System V: msg… (man msgget) ou POSIX mq_… (man 7 mq_overview).
qu’en pensez vous ?
(it’s raining man , alleluia )[/quote]
C’est correct si j’ai bien compris, mais ça n’a pas les mêmes effets qu’un pipe il me semble…
Par exemple, tu ne pourrais pas implémenter “|”
Enfin, si je dis pas de bétises
Ça dépend de ce que tu as à faire. L’architecture de ton application et le type de donnée que tu partage choisissent le moyen de communication.
Les signaux quand on veut juste “signaler” un événement à un autre processus.
Les pipe lorsque que l’on communique régulièrement de petits messages.
Les files de messages sont plus pratique lorsque les messages sont plus complexe.
Pour ce qui est de fifo, c’est surtout utile quand il n’y a pas de relation pere-fils entre les processus.
[quote=“MisterFreez”]Ça dépend de ce que tu as à faire. L’architecture de ton application et le type de donnée que tu partage choisissent le moyen de communication.
Les signaux quand on veut juste “signaler” un événement à un autre processus.
Les pipe lorsque que l’on communique régulièrement de petits messages.
Les files de messages sont plus pratique lorsque les messages sont plus complexe.
Pour ce qui est de fifo, c’est surtout utile quand il n’y a pas de relation pere-fils entre les processus.[/quote]
J’aurais pas dit mieux