Demande de confirmation sur la programmation systeme

Version imprimable

Bonjour, je dois faire un projet de système en langage C sur les sémaphores, mon problème est que j'ai 2 processus : un lecteur et un écrivain.
Ma question est la suivante :
faut-il bien 1 fork pour chaque processus donc un fork contenant le processus lecteur et un autre comprenant le processus ecrivain ?

Ce qui me donnerai ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 if ((n=fork())==-1) { perror("erreur fork"); exit(1); } else { if (n==0) { //ici juste le processus fils ecrivain } else { //ici le père mais a quoi sert-il ??? } } if ((n2=fork())==-1) { perror("erreur fork"); exit(1); } else { if (n==0) { //ici juste le processu fils lecteur } else { //ici le père mais a quoi sert-il ??? } }
Comme j'ai mis en commentaire : a quoi sert/peut servir le processus père ? et à la fin du processus fils je présume qu'il faut un exit pour terminer le processus fils, est correcte ?

donc un résumé des questions :

Faut-il bien 1 fork pour chaque processus donc un fork contenant le processus lecteur et un autre comprenant le processus écrivain ?
A quoi sert/peut servir le processus père ? parce que du coup je ne vois pas trop son but
Faut-il un exit pour terminer le processus fils ?
Et bien sûr est ce que mon raisonnement est juste du point de vue agencement des processus ?

14/11/2008, 20h29
nicolas.sitbon

à la suite d'un fork(), tu as 2 processus donc inutile de faire 2 fork(). Les 2 processus exécutent le même code, la seule chose qui les différentie est le retour de fork(), 0 dans le cas du fils, et le pid du fils dans le cas du père ou -1 en cas d'erreur.

Code:

1 2 3 4 5 6 7 8 9 10 11 n = fork(); switch(n) { case -1 : perror("echec fork"); break; case 0 : //ici le code de l'écrivain typiquement des fwrite break; case 1 : //ici le code du lecteur typiquement des fread break; }
Le code du lecteur et écrivain peut être écrit dans d'autres fichiers .c du coup on utilise les fonctions excelp etc plutot que d'écrire tout le code à la sauvage dans le case d'un switch.

Après le fork tu as 2 processus concurrent qui s'executent à partir de la ligne qui suit c'est à dire que les 2 executent le switch en fonction de n soit le process ira executer le code du lecteur ou alors de l'écrivain

14/11/2008, 21h48
matafan

On peut tout à fait mettre le code de l'ecrivain et du lecteur dans deux fichiers .c différents, sans pour autant faire d'exec.

Aussi dans ton switch tu voulais dire "default", pas "case 1". Dans le père, fork retourne le pid du fils, pas 1. D'ailleurs il vaut mieux faire des if qu'un switch, puisque rien ne garentit qu'un pid_t tient dans un int.
14/11/2008, 22h19
nicolas.sitbon

Citation:

Envoyé par matafan

D'ailleurs il vaut mieux faire des if qu'un switch, puisque rien ne garentit qu'un pid_t tient dans un int.

je ne vois pas le rapport entre l'instruction switch et le type int?!!
14/11/2008, 22h39
matafan

Je me basais sur ça :

Citation:

6.8.4.2 The switch statement
Constraints
The controlling expression of a switch statement shall have integer type.

Mais effectivement "integer" ne veux pas dire "int"
14/11/2008, 22h51
hegros

Citation:

Envoyé par matafan

Je me basais sur ça :

Mais effectivement "integer" ne veux pas dire "int"

euh int c'est le diminutif de integer... Autant tu me dirais que fork ne retourne pas un integer mais un pid_t pourquoi pas la flemme de chercher dans la doc.
14/11/2008, 22h54
nicolas.sitbon

Citation:

Envoyé par hegros

euh int c'est le diminutif de integer...

Oui mais dans ce cas integer ne signifie pas le type int.
14/11/2008, 22h55
matafan

Citation:

Envoyé par hegros

euh int c'est le diminutif de integer... Autant tu me dirais que fork ne retourne pas un integer mais un pid_t pourquoi pas la flemme de chercher dans la doc.

Non, dans la norme "integer" ça représente n'importe quel type entier : char, short, int, long, long long... fork retourne un pid_t, qui est bien un "integer" (en général un int ou un long ou un long long). Donc à priori pas de problème dans un switch.
14/11/2008, 22h59
nicolas.sitbon

Citation:

Envoyé par matafan

fork retourne un pid_t, qui est bien un "integer" (en général un int ou un long ou un long long).

Non :

Citation:

The implementation shall support one or more programming environments in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t, and useconds_t are no greater than the width of type long.
14/11/2008, 23h06
hegros

Là c'est vraiment pointu pour moi. Normalement il devrait y avoir un cast implicite de pid_t vers int, un débordement qui provoquerait un comportement chelou viendrait d'un bug de fork ? :oops:
14/11/2008, 23h08
amateurc

avez-vous des liens ou des exemples de programme pour que j'ai un exemple concret d'utilisation ?(de préférence avec des sémaphores)
14/11/2008, 23h09
nicolas.sitbon

Citation:

Envoyé par hegros

Normalement il devrait y avoir un cast implicite de pid_t vers int, un débordement qui provoquerait un comportement chelou viendrait d'un bug de fork ? :oops:

Là j'avoue avoir du mal à te suivre, de quoi parles tu?
14/11/2008, 23h11
hegros

Citation:

Envoyé par nicolas.sitbon

Là j'avoue avoir du mal à te suivre, de quoi parles tu?

Vos histoires de norme c'est tout aussi clair pour moi !

Donc ca donnerai :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
if ((n=fork())==-1)
{
	perror("erreur fork");
	exit(1);
}
else
{
	if (n==0)
	{
		//ici juste le processus fils ecrivain
                exit(0);//on termine le processus ecrivain
	}
	if (n==1)
        {
		//ici le processus redacteur
		exit(0);//on le termine
	}
}

mais est ce que pour n==1 ce n'est pas le processus père qui s'execute ?

14/11/2008, 23h30
hegros

Il faut lire la documentation tout les détails y sont.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
#include <unistd.h>
#include <stdio.h>
 
#define MESSAGE "Hello world\n"
 
int main (void)
{
   int fildes[2];
 
   if (pipe (fildes) == -1)
   {
      perror ("pipe");
   }
   else
   {
      switch (fork ())
      {
         case -1:
            perror ("fork");
            break;
         case 0: /* fils, ecrivain */
            close (fildes[0]), fildes[0] = -1; /* le descripteur en lecture ne nous sert à rien */
 
            write (fildes[1], MESSAGE, sizeof MESSAGE - 1);
            close (fildes[1]), fildes[1] = -1;
            break;
         default: /* pere, lecteur */
         {
            char buf[sizeof MESSAGE - 1];
            ssize_t read_len = 0;
 
            close (fildes[1]), fildes[1] = -1; /* le descripteur en ecriture ne nous sert à rien */
 
            read_len = read (fildes[0], buf, sizeof buf);
 
            if (read_len > 0)
            {
               write (STDOUT_FILENO, buf, (size_t) read_len);
            }
 
            close (fildes[0]), fildes[0] = -1;
         }
      }
   }
 
   return 0;
}

15/11/2008, 00h18
Médinoc

Citation:

Envoyé par nicolas.sitbon

Citation:

no greater than long

C'est quelle version de la norme, ça ?
Il me semblait que les versions les plus récentes avaient une exception pour les architectures LLP64, où un size_t est plus grand qu'un long...
15/11/2008, 00h23
nicolas.sitbon

Citation:

Envoyé par Médinoc

C'est quelle version de la norme, ça ?
Il me semblait que les versions les plus récentes avaient une exception pour les architectures LLP64, où un size_t est plus grand qu'un long...

C'est POSIX (pid_t n'est pas dans le standard C), et dans ce cas précis, cette considération n'a pas trop d'importance.
15/11/2008, 10h16
matafan

Celà dit ne ne vois pas trop en quoi ta citation contredit ce que j'ai dit. Il y a des plateformes sur lesquels un long long n'est pas plus long qu'un long.

En fait j'avait inclu long long parce qu'il me semble bien que pid_t est un long long sous AIX, mais je n'en ai pas sous la main pour vérifier.
15/11/2008, 12h42
Médinoc

Il me semble que toutes les plate-formes POSIX 64 bits utilisent le modèle LP64 (notez: un seul L), donc long ou long long, c'est pareil.
16/11/2008, 11h21
amateurc

D'accord merci pour vos précisions