Discussion :

[Fortran90]

Bonjour,

Mon but est de bufferiser dans une variable tous les outputs, sur stderr ou stdin de routines appelés dans une librairie qui utilise du C et du fortran.

Voilà où j'en suis après qques moments passé sur google.

Si intercepter des outputs (par cout) en C++ est assez simple (utilisation des stringstream et consort), et que pour le C on pour se débroutiller par setbuf/setvbuf, je ne trouve aucun moyen pour intercepter les outputs de program fortran ( la méthode setbuf ne marche pas).

Je cherche donc un moyen d'intercepter tous les outputs et les enregistrer dans un buffer qui marcherait pour C/fortran..

Une idée?

[phi1981]

Il est aussi possible de rediriger les sorties stderr et stdout de tout un programme vers un pipe et de lire ce pipe, tu en penses quoi ?

[3DArchi]

Salut,
Creating a Child Process with Redirected Input and Output pour windows

[Fortran90]

Malheureusement l'idée de créer un processus fils pour intercepter les outputs ne me semble pas viable:

1/ les routines utilisées dont je veux intercepter l'output peuvent être multithreadés via OpenMP
2/ je travaille de surcroît dans un environnement MPI

L'idée de forker des processes (un par process MPI) risque de bloquer mes ressources et d'overloader la machine juste pour trapper des outputs....

A moins que je comprenne pas qqchose.

[3DArchi]

La création d'un child process c'est juste pour lancer un exécutable dont tu veux mapper les entrées/sorties (stdin,err,out) sur des pipes maîtrisées par ton processus de bufferisation. Ensuite, que cet exécutable distribue son calcul, grand bien lui fasse du moment que la gestion des I/O est correcte.

[Fortran90]

Si par exemple j'ai 4 coeurs sur ma machine...
Je lance le programme sur 1 process.
Je spawne un process pour trapper les outputs.
Le process spawné va utiliser des pragmas OpenMP ou autres, sur 4 threads.

Si je compte bien ça fait 5 processes sur une machine de 4 coeurs. Et ça c'est pas bon. Il faut bien que le process père continue à vivre pour récupérer les out de son fils via le pipe...

On a donc un process en trop qui spin à 100% de consommation CPU, pour rien. Enfin si pour des outputs qui arriveront plus lentement...