bonsoir, je ne suis peut etre pas ds le bon forum desolé,
pour afficher les resultats de mes threads ont m'a conseillé les named
pipes. cela semble *simple* a mettre en oeuvre. je trouve sur le net que
des ex en c. (rien dans le stroustrup)
citation "Si tu veux du non-bloquant, utilises plutôt open et les flag
O_WRONLY|O_NONBLOCK"
je prefererai utiliser un ofstream (c++) si possible et quel parametre
passer specifiant le mode d'ouverture. rien vu dans openmode
le fichier sera visualisé dans un ternimal avec cat.
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
Fabien LE LEZ
On Wed, 4 Jan 2006 23:27:13 +0100, (Bruno Causse):
pour afficher les resultats de mes threads ont m'a conseillé les named pipes. cela semble *simple* a mettre en oeuvre. je trouve sur le net que des ex en c. (rien dans le stroustrup)
Le Stroustrup parle du langage C++. Les "named pipes" sont des extensions qu'on trouve sur quelques OS, mais pas forcément compatibles entre elles.
Pour les détails d'utilisation, tu trouveras sans doute plus d'aide sur un forum consacré à ton système d'exploitation.
Toutefois, je suis perplexe, voire dubitatif : les pipes servent généralement à la communication entre processus indépendants ; pour la communication entre plusieurs threads du même processus, j'aurais plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel objet, puisque tous les threads d'un processus ont accès à la même zone mémoire, mais avec les mutex qui vont bien pour empêcher les différents threads de se marcher sur les pieds).
On Wed, 4 Jan 2006 23:27:13 +0100, pasde.hcyrano.spam@free.fr (Bruno
Causse):
pour afficher les resultats de mes threads ont m'a conseillé les named
pipes. cela semble *simple* a mettre en oeuvre. je trouve sur le net que
des ex en c. (rien dans le stroustrup)
Le Stroustrup parle du langage C++. Les "named pipes" sont des
extensions qu'on trouve sur quelques OS, mais pas forcément
compatibles entre elles.
Pour les détails d'utilisation, tu trouveras sans doute plus d'aide
sur un forum consacré à ton système d'exploitation.
Toutefois, je suis perplexe, voire dubitatif : les pipes servent
généralement à la communication entre processus indépendants ; pour la
communication entre plusieurs threads du même processus, j'aurais
plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel
objet, puisque tous les threads d'un processus ont accès à la même
zone mémoire, mais avec les mutex qui vont bien pour empêcher les
différents threads de se marcher sur les pieds).
On Wed, 4 Jan 2006 23:27:13 +0100, (Bruno Causse):
pour afficher les resultats de mes threads ont m'a conseillé les named pipes. cela semble *simple* a mettre en oeuvre. je trouve sur le net que des ex en c. (rien dans le stroustrup)
Le Stroustrup parle du langage C++. Les "named pipes" sont des extensions qu'on trouve sur quelques OS, mais pas forcément compatibles entre elles.
Pour les détails d'utilisation, tu trouveras sans doute plus d'aide sur un forum consacré à ton système d'exploitation.
Toutefois, je suis perplexe, voire dubitatif : les pipes servent généralement à la communication entre processus indépendants ; pour la communication entre plusieurs threads du même processus, j'aurais plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel objet, puisque tous les threads d'un processus ont accès à la même zone mémoire, mais avec les mutex qui vont bien pour empêcher les différents threads de se marcher sur les pieds).
Bruno CAUSSE
dans l'article , Fabien LE LEZ à a écrit le 5/01/06 0:12 :
Toutefois, je suis perplexe, voire dubitatif : les pipes servent généralement à la communication entre processus indépendants ;
Probleme de depart : je cherche un moyen d'afficher en temps reel l'avancement d'une recherche alpha-beta.
En monothread pas de probleme std::cout et la fenetre du terminal me conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la meme sortie (peu lisible).
On m'a conseillé les named pipes. Ecriture dans un fichier et lecture en temps reel dans une nouvelle fenetre du terminal (cmd cat) == communication inter process.
Les seuls exemples que j'ai trouvé son en c avec open et sprintf. Je prefererai ouvrir mon fichier avec un ofstream et ecrire avec << et que les ecritures soit non bloquantes (lecture non obligatoire).
pour la communication entre plusieurs threads du même processus, j'aurais plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel objet, puisque tous les threads d'un processus ont accès à la même zone mémoire, mais avec les mutex qui vont bien pour empêcher les différents threads de se marcher sur les pieds).
mes threads de recherche ne communiquent pas entre eux (recherche sur deux positions differentes).
Voilà
Si tu as une autre idee.
Merci pour votre attention.
dans l'article 58lor1ho7glomjkn6mn8gh82m9flbamqm4@4ax.com, Fabien LE LEZ à
gramster@gramster.com a écrit le 5/01/06 0:12 :
Toutefois, je suis perplexe, voire dubitatif : les pipes servent
généralement à la communication entre processus indépendants ;
Probleme de depart : je cherche un moyen d'afficher en temps reel
l'avancement d'une recherche alpha-beta.
En monothread pas de probleme std::cout et la fenetre du terminal me
conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la
meme sortie (peu lisible).
On m'a conseillé les named pipes. Ecriture dans un fichier et lecture en
temps reel dans une nouvelle fenetre du terminal (cmd cat) == communication
inter process.
Les seuls exemples que j'ai trouvé son en c avec open et sprintf. Je
prefererai ouvrir mon fichier avec un ofstream et ecrire avec << et que les
ecritures soit non bloquantes (lecture non obligatoire).
pour la
communication entre plusieurs threads du même processus, j'aurais
plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel
objet, puisque tous les threads d'un processus ont accès à la même
zone mémoire, mais avec les mutex qui vont bien pour empêcher les
différents threads de se marcher sur les pieds).
mes threads de recherche ne communiquent pas entre eux (recherche sur deux
positions differentes).
En monothread pas de probleme std::cout et la fenetre du terminal me conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la meme sortie (peu lisible).
On m'a conseillé les named pipes. Ecriture dans un fichier et lecture en temps reel dans une nouvelle fenetre du terminal (cmd cat) == communication inter process.
Les seuls exemples que j'ai trouvé son en c avec open et sprintf. Je prefererai ouvrir mon fichier avec un ofstream et ecrire avec << et que les ecritures soit non bloquantes (lecture non obligatoire).
pour la communication entre plusieurs threads du même processus, j'aurais plutôt tendance à utiliser un objet "partagé" (i.e. n'importe quel objet, puisque tous les threads d'un processus ont accès à la même zone mémoire, mais avec les mutex qui vont bien pour empêcher les différents threads de se marcher sur les pieds).
mes threads de recherche ne communiquent pas entre eux (recherche sur deux positions differentes).
Voilà
Si tu as une autre idee.
Merci pour votre attention.
kanze
Bruno Causse wrote:
bonsoir, je ne suis peut etre pas ds le bon forum desolé,
Mais si tu sais que ce n'est pas le bon forum, pourquoi y poster quand même ? (En fait, j'ai l'impression que tu as plusieurs questions, dont au moins un qui convient ici.)
pour afficher les resultats de mes threads ont m'a conseillé les named pipes.
Je ne suis pas sûr de comprendre. Les « named pipes » sont une particularité d'Unix, qui peuvent servir à la communication entre plusieurs processus. Ils n'ont rien à voir avec un affichage quelconque, au moins qu'ils communiquent avec une application graphique qui s'occupe de l'affichage. (À vrai dire, je ne les utilise pas souvent pour la communication entre processus non plus ; je préfère les sockets.)
cela semble *simple* a mettre en oeuvre. je trouve sur le net que des ex en c. (rien dans le stroustrup)
C'est peut-être parce qu'il parle du C++ portable, et non des choses spécifiques à un système particulier.
citation "Si tu veux du non-bloquant, utilises plutôt open et les flag O_WRONLY|O_NONBLOCK"
C'est de la norme Posix. Si tu veux des détails, il vaut mieux démander dans le groupe Unix.
je prefererai utiliser un ofstream (c++) si possible et quel parametre passer specifiant le mode d'ouverture. rien vu dans openmode
Il n'y a rien dans l'interface des iostream qui supporte les entrées/sorties non bloquantes. On pourrait créer son propre streambuf qui le fait, mais c'est à toi de le faire.
Dans un contexte multi-thread, quel est l'intérêt des entrées/sorties non bloquantes ? Si on ne veut pas bloquer, on créer un nouveau thread pour le faire.
le fichier sera visualisé dans un ternimal avec cat.
Et pourquoi pas simplement un fichier classique, avec tail -f ?
J'avoue comprendre de moins en moins. Les sorties vers un fichier ne se block jamais. Alors, d'où l'intérêt de « non bloquant ? (Les sorties vers un FIFO où c'est cat qui lit ne vont pas bloquer non plus.)
l'idee est elle bonne et avez vous un exemple?
Il faudrait que tu expliques un peu mieux ce que tu cherches à faire, mais j'ai l'impression que :
-- Écrire dans un fichier normal, et utiliser tail -f pour l'affichage, ferait l'affaire. Voire même écrire directement sur cout.
-- Si tu veux vraiment utiliser un FIFO, une fois qu'il est créé, il s'utilise exactement comme un fichier. Pour le créer, soit mknod, dans ton programme, soit mkfifo, comme commande au niveau de shell. (Pour plus d'information, voir dans le groupe Unix.)
-- Le seul effet O_NONBLOCK que je peux voir dans ce que tu décrit, c'est que si tu utilises le FIFO, l'ouverture en écriture échouera si aucun processus n'ait le FIFO ouvert en lecture. Je ne sais vraiment pas si ça vaut la peine.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bruno Causse wrote:
bonsoir, je ne suis peut etre pas ds le bon forum desolé,
Mais si tu sais que ce n'est pas le bon forum, pourquoi y poster
quand même ? (En fait, j'ai l'impression que tu as plusieurs
questions, dont au moins un qui convient ici.)
pour afficher les resultats de mes threads ont m'a conseillé
les named pipes.
Je ne suis pas sûr de comprendre. Les « named pipes » sont une
particularité d'Unix, qui peuvent servir à la communication
entre plusieurs processus. Ils n'ont rien à voir avec un
affichage quelconque, au moins qu'ils communiquent avec une
application graphique qui s'occupe de l'affichage. (À vrai dire,
je ne les utilise pas souvent pour la communication entre
processus non plus ; je préfère les sockets.)
cela semble *simple* a mettre en oeuvre. je trouve sur le net
que des ex en c. (rien dans le stroustrup)
C'est peut-être parce qu'il parle du C++ portable, et non des
choses spécifiques à un système particulier.
citation "Si tu veux du non-bloquant, utilises plutôt open et
les flag O_WRONLY|O_NONBLOCK"
C'est de la norme Posix. Si tu veux des détails, il vaut mieux
démander dans le groupe Unix.
je prefererai utiliser un ofstream (c++) si possible et quel
parametre passer specifiant le mode d'ouverture. rien vu dans
openmode
Il n'y a rien dans l'interface des iostream qui supporte les
entrées/sorties non bloquantes. On pourrait créer son propre
streambuf qui le fait, mais c'est à toi de le faire.
Dans un contexte multi-thread, quel est l'intérêt des
entrées/sorties non bloquantes ? Si on ne veut pas bloquer, on
créer un nouveau thread pour le faire.
le fichier sera visualisé dans un ternimal avec cat.
Et pourquoi pas simplement un fichier classique, avec tail -f ?
J'avoue comprendre de moins en moins. Les sorties vers un
fichier ne se block jamais. Alors, d'où l'intérêt de « non
bloquant ? (Les sorties vers un FIFO où c'est cat qui lit ne
vont pas bloquer non plus.)
l'idee est elle bonne et avez vous un exemple?
Il faudrait que tu expliques un peu mieux ce que tu cherches à
faire, mais j'ai l'impression que :
-- Écrire dans un fichier normal, et utiliser tail -f pour
l'affichage, ferait l'affaire. Voire même écrire directement
sur cout.
-- Si tu veux vraiment utiliser un FIFO, une fois qu'il est
créé, il s'utilise exactement comme un fichier. Pour le
créer, soit mknod, dans ton programme, soit mkfifo, comme
commande au niveau de shell. (Pour plus d'information, voir
dans le groupe Unix.)
-- Le seul effet O_NONBLOCK que je peux voir dans ce que tu
décrit, c'est que si tu utilises le FIFO, l'ouverture en
écriture échouera si aucun processus n'ait le FIFO ouvert
en lecture. Je ne sais vraiment pas si ça vaut la peine.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
bonsoir, je ne suis peut etre pas ds le bon forum desolé,
Mais si tu sais que ce n'est pas le bon forum, pourquoi y poster quand même ? (En fait, j'ai l'impression que tu as plusieurs questions, dont au moins un qui convient ici.)
pour afficher les resultats de mes threads ont m'a conseillé les named pipes.
Je ne suis pas sûr de comprendre. Les « named pipes » sont une particularité d'Unix, qui peuvent servir à la communication entre plusieurs processus. Ils n'ont rien à voir avec un affichage quelconque, au moins qu'ils communiquent avec une application graphique qui s'occupe de l'affichage. (À vrai dire, je ne les utilise pas souvent pour la communication entre processus non plus ; je préfère les sockets.)
cela semble *simple* a mettre en oeuvre. je trouve sur le net que des ex en c. (rien dans le stroustrup)
C'est peut-être parce qu'il parle du C++ portable, et non des choses spécifiques à un système particulier.
citation "Si tu veux du non-bloquant, utilises plutôt open et les flag O_WRONLY|O_NONBLOCK"
C'est de la norme Posix. Si tu veux des détails, il vaut mieux démander dans le groupe Unix.
je prefererai utiliser un ofstream (c++) si possible et quel parametre passer specifiant le mode d'ouverture. rien vu dans openmode
Il n'y a rien dans l'interface des iostream qui supporte les entrées/sorties non bloquantes. On pourrait créer son propre streambuf qui le fait, mais c'est à toi de le faire.
Dans un contexte multi-thread, quel est l'intérêt des entrées/sorties non bloquantes ? Si on ne veut pas bloquer, on créer un nouveau thread pour le faire.
le fichier sera visualisé dans un ternimal avec cat.
Et pourquoi pas simplement un fichier classique, avec tail -f ?
J'avoue comprendre de moins en moins. Les sorties vers un fichier ne se block jamais. Alors, d'où l'intérêt de « non bloquant ? (Les sorties vers un FIFO où c'est cat qui lit ne vont pas bloquer non plus.)
l'idee est elle bonne et avez vous un exemple?
Il faudrait que tu expliques un peu mieux ce que tu cherches à faire, mais j'ai l'impression que :
-- Écrire dans un fichier normal, et utiliser tail -f pour l'affichage, ferait l'affaire. Voire même écrire directement sur cout.
-- Si tu veux vraiment utiliser un FIFO, une fois qu'il est créé, il s'utilise exactement comme un fichier. Pour le créer, soit mknod, dans ton programme, soit mkfifo, comme commande au niveau de shell. (Pour plus d'information, voir dans le groupe Unix.)
-- Le seul effet O_NONBLOCK que je peux voir dans ce que tu décrit, c'est que si tu utilises le FIFO, l'ouverture en écriture échouera si aucun processus n'ait le FIFO ouvert en lecture. Je ne sais vraiment pas si ça vaut la peine.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Matthieu Moy
Bruno CAUSSE writes:
En monothread pas de probleme std::cout et la fenetre du terminal me conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la meme sortie (peu lisible).
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla thread2: toto titi ...
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les fichiers en question sont des pipes nommés (man mkfifo), tu pourras lancer des "cat logs/threadX" dans plusieurs terminaux par exemple. Si ce sont des fichiers "normaux", tu peux toujours faire un "tail -f logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera un peu moins fluide je pense).
Mais là, tu devrais aller sur fr.comp.os.unix pour les détails.
-- Matthieu
Bruno CAUSSE <envoi@lesSpam.fr> writes:
En monothread pas de probleme std::cout et la fenetre du terminal me
conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la
meme sortie (peu lisible).
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien
pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla
thread2: toto titi
...
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers
séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les
fichiers en question sont des pipes nommés (man mkfifo), tu pourras
lancer des "cat logs/threadX" dans plusieurs terminaux par exemple. Si
ce sont des fichiers "normaux", tu peux toujours faire un "tail -f
logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera
un peu moins fluide je pense).
Mais là, tu devrais aller sur fr.comp.os.unix pour les détails.
En monothread pas de probleme std::cout et la fenetre du terminal me conviennent parfaitement.
En multithread, les differentes recherches ne peuvent pas s'afficher dans la meme sortie (peu lisible).
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla thread2: toto titi ...
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les fichiers en question sont des pipes nommés (man mkfifo), tu pourras lancer des "cat logs/threadX" dans plusieurs terminaux par exemple. Si ce sont des fichiers "normaux", tu peux toujours faire un "tail -f logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera un peu moins fluide je pense).
Mais là, tu devrais aller sur fr.comp.os.unix pour les détails.
-- Matthieu
Bruno CAUSSE
dans l'article , Matthieu Moy à a écrit le 5/01/06 10:02 :
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla thread2: toto titi
c'est cela que je qualifie d'illisible.
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les fichiers en question sont des pipes nommés (man mkfifo), tu pourras lancer des "cat logs/threadX" dans plusieurs terminaux par exemple.
C'est cela que l'on ma conseillé.
Je ne l'ai pas encore implementé, je cherchais des ex sur le net. Puis je ouvrir et ecrire ds les fichiers (pipes nommés) sans les lire.
ce sont des fichiers "normaux", tu peux toujours faire un "tail -f logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera un peu moins fluide je pense).
Je ne connais pas non plus je vais me renseigner.
merci
PS: je fais de la programmation pour mes loisirs (simple basic amateur)
dans l'article vpqhd8jyrlo.fsf@ecrins.imag.fr, Matthieu Moy à
MatthieuNOSPAM.Moy@imag.fr.invalid a écrit le 5/01/06 10:02 :
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien
pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla
thread2: toto titi
c'est cela que je qualifie d'illisible.
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers
séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les
fichiers en question sont des pipes nommés (man mkfifo), tu pourras
lancer des "cat logs/threadX" dans plusieurs terminaux par exemple.
C'est cela que l'on ma conseillé.
Je ne l'ai pas encore implementé, je cherchais des ex sur le net.
Puis je ouvrir et ecrire ds les fichiers (pipes nommés) sans les lire.
ce sont des fichiers "normaux", tu peux toujours faire un "tail -f
logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera
un peu moins fluide je pense).
Je ne connais pas non plus je vais me renseigner.
merci
PS: je fais de la programmation pour mes loisirs (simple basic amateur)
dans l'article , Matthieu Moy à a écrit le 5/01/06 10:02 :
A ta place, j'utiliserais la même sortie, avec le mutex qui va bien pour éviter les enchevêtrements. Éventuellement un préfixe genre
thread1: blablabla thread2: toto titi
c'est cela que je qualifie d'illisible.
Sinon, tu dis à ton programme de faire ses sorties dans des fichiers séparés (genre logs/thread1, logs/thread2, ...). Sous Unix, si les fichiers en question sont des pipes nommés (man mkfifo), tu pourras lancer des "cat logs/threadX" dans plusieurs terminaux par exemple.
C'est cela que l'on ma conseillé.
Je ne l'ai pas encore implementé, je cherchais des ex sur le net. Puis je ouvrir et ecrire ds les fichiers (pipes nommés) sans les lire.
ce sont des fichiers "normaux", tu peux toujours faire un "tail -f logs/threadX" dessus (mais ça utilisera de l'espace disque, et ça sera un peu moins fluide je pense).
Je ne connais pas non plus je vais me renseigner.
merci
PS: je fais de la programmation pour mes loisirs (simple basic amateur)
Matthieu Moy
Bruno CAUSSE writes:
Je ne l'ai pas encore implementé, je cherchais des ex sur le net. Puis je ouvrir et ecrire ds les fichiers (pipes nommés) sans les lire.
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu peux lire plus tard, c'est un fichier, non ?
-- Matthieu
Bruno CAUSSE <envoi@lesSpam.fr> writes:
Je ne l'ai pas encore implementé, je cherchais des ex sur le net.
Puis je ouvrir et ecrire ds les fichiers (pipes nommés) sans les lire.
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu
peux lire plus tard, c'est un fichier, non ?
dans l'article , Matthieu Moy à a écrit le 5/01/06 10:42 :
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu peux lire plus tard, c'est un fichier, non ?
Oui :-) , mais je veux avoir le choix soit les lire en direct, soit les lire plus tard.
Jean-Marc Bourguet
Bruno CAUSSE writes:
dans l'article , Matthieu Moy à a écrit le 5/01/06 10:42 :
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu peux lire plus tard, c'est un fichier, non ?
Oui :-) , mais je veux avoir le choix soit les lire en direct, soit les lire plus tard.
Mais tu peux lire un fichier pendant qu'il est ecrit par ailleurs (au moins sous Unix). Un named pipe par contre a normalement une capacite de stockage fini (quelques Ko) et l'ecriture fini par bloquer.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bruno CAUSSE <envoi@lesSpam.fr> writes:
dans l'article vpqfyo3j9iz.fsf@ecrins.imag.fr, Matthieu Moy à
MatthieuNOSPAM.Moy@imag.fr.invalid a écrit le 5/01/06 10:42 :
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu
peux lire plus tard, c'est un fichier, non ?
Oui :-) , mais je veux avoir le choix soit les lire en direct, soit les lire
plus tard.
Mais tu peux lire un fichier pendant qu'il est ecrit par ailleurs (au
moins sous Unix). Un named pipe par contre a normalement une capacite
de stockage fini (quelques Ko) et l'ecriture fini par bloquer.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
dans l'article , Matthieu Moy à a écrit le 5/01/06 10:42 :
Un truc dans lequel tu peux écrire, qui stoque les données, et que tu peux lire plus tard, c'est un fichier, non ?
Oui :-) , mais je veux avoir le choix soit les lire en direct, soit les lire plus tard.
Mais tu peux lire un fichier pendant qu'il est ecrit par ailleurs (au moins sous Unix). Un named pipe par contre a normalement une capacite de stockage fini (quelques Ko) et l'ecriture fini par bloquer.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bruno CAUSSE
Bon je résume,
Si j'ai bien compris:
Un fichier texte ordinaire et la cmd tail -f sont suffisant pour mon problème. :-)
Merci de vos précieux éclairages.
Bon je résume,
Si j'ai bien compris:
Un fichier texte ordinaire et la cmd tail -f sont suffisant pour mon
problème. :-)
