Discussion :

[amateurc]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

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

[hegros]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[nicolas.sitbon]

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?!!

[matafan]

Je me basais sur ça :

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"

[hegros]

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.

[nicolas.sitbon]

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

Oui mais dans ce cas integer ne signifie pas le type int.

[matafan]

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.

[nicolas.sitbon]

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

Non :

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.

[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 ?

[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)

[nicolas.sitbon]

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 ?

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

[hegros]

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

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

[amateurc]

Donc ca donnerai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[hegros]

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

[nicolas.sitbon]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

[Médinoc]

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

[nicolas.sitbon]

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.

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