Bonjour, Je suis confronté à un problème aujourd'hui ... qui m'occupe ! J'ai une application qui lit des informations dans un tube nommé, et un petit programme en C++ qui écoute le réseau et va écrire dans le tube nommé ci-dessus les infos reçues. Ma question est la suivante : puis-je connaitre le nombre d'octets en attente de lecture dans le pipe autrement qu'en modifiant le code C++ ? (sans les lire ;-) Question subsidiaire (et hors-sujet shell) qui gére l'écriture mémoire sous linux, le noyau ou le processus lui-même ? En fait cette question vient d'un débat commencé avec un collègue où j'avançais que le noyau était le seul composant capable de savoir combien de caractères étaient en attente de lecture dans le pipe, lui pense que ca se situerait plutot au niveau de la bibliothèque C standard (et que le noyau n'en sait fichtre rien, puisque c'est pas son boulot) ... S'il y avait quelqu'un pour m'éviter un weekend de lecture de la gestion mémoire du noyau, ce serait sympa ! ;-) Jeremy PS : je suis preneur de tout lien explicatif, documentation, etc ! -- Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them. Please send me only open formats, as OpenDocument or pdf.
On ven 01 septembre, Jeremy Monnet wrote:
Bonjour,
Je suis confronté à un problème aujourd'hui ... qui m'occupe ! J'ai une application qui lit des informations dans un tube nommé, et un petit programme en C++ qui écoute le réseau et va écrire dans le tube nommé ci-dessus les infos reçues.
Ma question est la suivante : puis-je connaitre le nombre d'octets en attente de lecture dans le pipe autrement qu'en modifiant le code C++ ? (sans les lire ;-)
Aucune idée malheureusement :/ Vu qu'un FIFO n'est qu'un device, il y a peut être un ioctl ou autre qui va bien, je ne vois pas trop :/
Question subsidiaire (et hors-sujet shell) qui gére l'écriture mémoire sous linux, le noyau ou le processus lui-même ? En fait cette question vient d'un débat commencé avec un collègue où j'avançais que le noyau était le seul composant capable de savoir combien de caractères étaient en attente de lecture dans le pipe, lui pense que ca se situerait plutot au niveau de la bibliothèque C standard (et que le noyau n'en sait fichtre rien, puisque c'est pas son boulot) ... S'il y
La libc ne fais que manipuler l'espace utilisateur. Toute communication avec la mémoire noyau (sockets, etc..) se fait certes via des appels à la libc, mais ceux ci ne sont que des wrappers vers des appels systèmes noyaux (appelés via l'interruption virtuelle de linux). cf http://lxr.linux.no/source/include/linux/syscalls.h La libc c'est une librairie comme une autre, ce n'est pas un "processus" (comme l'est le noyau), je ne vois pas comment elle pourrait donc savoir ce genre de choses. My two cents -- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking Solaris User Group
On 9/1/06, Bruno Bonfils <asyd@asyd.net> wrote:
La libc ne fais que manipuler l'espace utilisateur. Toute communication avec la mémoire noyau (sockets, etc..) se fait certes via des appels à la libc, mais ceux ci ne sont que des wrappers vers des appels systèmes noyaux (appelés via l'interruption virtuelle de linux). Avec la mémoire *tout court*, sinon une application devrait se soucier de savoir (par exemple) si on atteint la RAM ou la SWAP. Alors qu'on s'en moque ! seul le noyau a une idée de ça. enfin il me semble ?
cf http://lxr.linux.no/source/include/linux/syscalls.h
La libc c'est une librairie comme une autre, ce n'est pas un "processus" (comme l'est le noyau), je ne vois pas comment elle pourrait donc savoir ce genre de choses.
Ben je pense à peu près la même chose. Mais j'ai un "windowsien" en face de moi (quoi, qui a vu passer un gros troll velu ?). Jeremy -- Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them. Please send me only open formats, as OpenDocument or pdf.
participants (2)
-
Bruno Bonfils
-
Jeremy Monnet