Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 26/01/2013, à 23:27

sin92

Instructions dans un processus

Bonjour voila y'a quelque chose que je n'arrive pas a comprendre je débute dans la programmation système :

voici mon code : il s'agit simplement de faire communiquer un processus père avec un processus fils

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void pipe_shell(char* argv1, char* argv2);

int main(int argc,char* argv[])
{
        if(argc!=3)
                 exit(-1);

	pipe_shell(argv[1],argv[2]);
		
	return EXIT_SUCCESS;
}

void pipe_shell(char* argv1, char* argv2)
{
	int tube[2];
	pipe(tube);
	pid_t result_fork=fork();

	switch(result_fork)
	{
		case -1 : printf("Erreur creation processus\n");
			exit(-1);

		case 0 : /*processus fils*/
                        printf("coucou");
			close(tube[1]);
			dup2(tube[0],0);
			close(tube[0]);
			execl("/usr/bin/sort","sort",NULL);
			break;

		default : /*processus pere*/
			printf("coucou");
			close(tube[0]);
			dup2(tube[1],1);
			close(tube[1]);
			execl("/bin/ls","ls",NULL);

	}
}

Pourquoi les printf("coucou"); ne s'exécutent pas?

De plus si j'ai bien compris les processus sont tués dès que leurs instructions sont terminés mais admettons que le fils doit envoyer un message au père via un pipe; Admettons que ce soit au père de s'exécuter en premier il va terminer ses instructions, voyant qu'il n'y a rien à lire pour le moment et ne pourra pas lire ce que le fils lui envoie puis va mourir? mais dans la réalité les deux arrivent à communiquer donc quand un processus meurt-il réellement?Tourne t-il en boucle plusieurs fois de suite?Ou lors de l'accès en lecture d'un descripteur va t-il se mettre en pause jusqu'a ce qu'une donnée apparaisse?

Merci !

Hors ligne

#2 Le 28/01/2013, à 08:28

Melrock

Re : Instructions dans un processus

sin92 a écrit :

Pourquoi les printf("coucou"); ne s'exécutent pas?

Les printf s’exécutent, mais la sortie standard est bufferisée. Le buffer est vidé à chaque retour chariot ou quand on lui demande explicitement (en ajoutant  fflush (stdout); après chaque printf) ou en faisant une lecture sur l'entrée standard. Dans ton cas, les 3 conditions sont fausses et manifestement (je l'ignorais roll) le execl repart d'un buffer vide pour sa sortie standard.

sin92 a écrit :

De plus si j'ai bien compris les processus sont tués dès que leurs instructions sont terminés mais admettons que le fils doit envoyer un message au père via un pipe; Admettons que ce soit au père de s'exécuter en premier il va terminer ses instructions, voyant qu'il n'y a rien à lire pour le moment et ne pourra pas lire ce que le fils lui envoie puis va mourir?

Tout dépend de la façon dont le père attend la lecture. En général une lecture sur l'entrée standard est bloquante : le process attend tant qu'il n'y a rien à lire. Mais on peut aussi le programmer de façon à ce qu'il n'attende pas et il mourra si son fils n'est pas assez rapide à lui écrire.

sin92 a écrit :

mais dans la réalité les deux arrivent à communiquer donc quand un processus meurt-il réellement?

Dans ton cas, le fils exécute "sort" qui reste bloquant en attendant qu'il arrive quelque chose sur son entrée standard et le père exécute "ls" qui envoie des données sur sa sortie standard donc sur l'entrée standard de son fils, puis meurt. Le fils cesse d'être bloqué par son entrée standard quand le pipe est rompu par la mort du père (à la fin de l'exéution du "ls"), fait alors le tri, affiche le résultat et meurt.

sin92 a écrit :

Tourne t-il en boucle plusieurs fois de suite?

Donc non.:P

sin92 a écrit :

Ou lors de l'accès en lecture d'un descripteur va t-il se mettre en pause jusqu'a ce qu'une donnée apparaisse?

Donc oui wink, sauf si on définit explicitement le descripteur comme non bloquant.

Dernière modification par Melrock (Le 28/01/2013, à 08:32)


Tout problème a sa solution, donc s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

Hors ligne

#3 Le 28/01/2013, à 13:32

sin92

Re : Instructions dans un processus

Merci beaucoup de ta réponse melrock si je commente la ligne du execl, le printf s'affiche normalement et comme le printf arrive avant le execl je me demandais le rapport de cause à effet.

Ok faut que je regarde toute cette histoire de blocage alors tongue

Dernière petite question : dans tous les cours "propres" que j'ai pu voir, il y a ces lignes :

close(tube[0]);
dup2(tube[1],1);
close(tube[1]);

La première, aucun souci on ferme le coté du tube qu'on utilise pas dans le processus.
La deuxième no souci non plus, on connecte les flux.
Mais la troisième : pourquoi ferme t'on le descripteur crée via un pipe si on doit l'utiliser par la suite?Ici, on connecte l'entrée du tube a la sortie standard mais pourquoi ferme t-on l'entrée du tube juste après?

Merci encore.

Hors ligne

#4 Le 29/01/2013, à 10:48

Melrock

Re : Instructions dans un processus

En fait tu peux très bien avoir plusieurs descripteurs ouverts sur un même fichier (un même flux, en l'occurrence, mais c'est pareil).
Quand tu fais dup2(tube[1],1) tu copie les paramètres du descripteur "tube[1]" dans le descripteur 1 (sortie standard).
A ce moment tu as deux descripteurs qui désignent le même flux.
"ls", comme tout le monde, écrit dans le flux du descripteur 1. Par contre, personne n'utilise plus le descripteur tube[1]. On peut donc fermer tube[1], c'est à dire casser la connexion entre le descripteur et le flux. Ça ne change rien au descripteur 1 qui, lui, reste connecté au flux.

idem, dans l'autre sens, pour "sort", l'entrée standard et tube[0]

Par ailleurs, c'est plutôt une bonne idée de fermer les descripteurs dont on n'a plus besoin. Après tout, il n'y en a qu'un nombre limité. C'est comme pour un fichier : quand tu as finit de le lire, ou quand tu n'as plus rien à y écrire, tu le fermes.


Tout problème a sa solution, donc s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

Hors ligne