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

[3DArchi]

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

[Fortran90]

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

[3DArchi]

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 ?

[Fortran90]

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

[Joel F]

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.

[Fortran90]

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?

[Fortran90]

Personne n'a id�e ?