Interception des outputs C/fortran depuis C++

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?

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 ?

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

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.

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.

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...

Citation:

---

Envoyé par Fortran90

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

---

Je ne sais pas trop ce que signifie spin, mais j'ose espérer qu'une attente sur un pipe n'est pas implémentée comme une attente active. Ensuite, de deux choses l'une : soit la tâche de bufferisation des E/S est déléguée à un process (ou un thread) dédié - ce qu'il m'avait semblé comprendre de ta question première - et alors il faut bien lui donner aussi du temps CPU pour réaliser sa tâche. Soit chaque tâche s'en occupe et alors cette gestion doit être explicitement faite au sein de celles-ci (ou avec un outil permettant de la programmation par aspect) mais ne peut plus être détachée dans un programme séparé.
Ou quelque chose m'échape :koi:

Par spin, il faut comprendre ce que tu as compris.

Le problème est que le type d'attente lors d'un pipe implémenté en C par exemple va dépendre, à mon humble avis, du compilateur. J'ai déjà vu un process qui était en attente active dans un wait après un fork avec le compilateur portland...d'où le sens de mes remarques.

De plus, si le process père pèse lourd en RAM, ce qui est mon cas, je ne peux pas me permettre de dupliquer le process par un fork.

Après je ne suis pas expert ès pipe...

J'ai l'impression qu'il y a quelque chose qui m'échappe : ton use-case, c'est quoi :
1/ Les librairies C et/ou Fortran sont invoquées depuis un processus qui veut monitorer leur E/S ?
2/ Les librairies C et/ou Fortran sont invoquées dans un processus différent de celui qui veut monitorer leur E/S ?

C'est la situation numéro 1. Typiquement un calcul hybride ( mpi et openMP ).

Si ton thread en attente spin à 100%, c'ets que ton OS est bien moisi. Un thread en attente via le scheduler ne consomme pas de ressource.

Tu te rends compte que la ta machine fait tourner 400-500 threads sur 2-4 cores rien que pour l'OS ? et que bon, ton CPU ets pas à 100 % ?

La solution de Archi3D est correcte.

Oh mais j'ai pas dit qu'elle n'est pas correcte.

J'ai juste dit que ça colle pas avec mes besoins. J'ai l'impression d'écraser une mouche avec une patte d'éléphant.

Par contre pour les processus tu as entièrement raison...et en fait je me souviens avoir vu ça pour des processus openMP pour le compilateur portland, rien à voir avec un OS moisi.

Par contre, j'aimerai être sûr...

Quand je fais le pipe, la mémoire des processus "père et fils" est elle dupliquée ou partagée?

Personne n'a idée ?