Forum Programmation.c communication entre fork() via un tableau en mémoire

Posté par  .
Étiquettes : aucune
0
25
jan.
2008
Bonjour,

Je cherche à partager un tableau de données unique afin de matérialiser la communication entre les fork(). L'idée est que le père renseigne ce tableau lors de chaque création de fils afin que ces derniers puissent s'échanger des informations, en incluant une notion de signal obligeant les fils à écrire dans ce tableau tour à tour.

On m'a suggéré d'utiliser un sémaphore ainsi qu'un segment de mémoire partagé, mais je n'arrive pas à reproduire un squelette sur ce type d'architecture...

J'avoue m'en remettre à vous, lassé de mes nuits blanches vaines :(
  • # Un exemple de code

    Posté par  (site web personnel) . Évalué à 2.

    Tu n'aurais pas un exemple de code à nous proposer, un dump des sorties ...?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # man IPC

    Posté par  . Évalué à 3.

    Je ne sais pas si tu as déjà regardé, mais tout ça est dans man IPC (puis man shmget, man semget, ...).

    Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais l'idée serait d'avoir une zone de mémoire partagée (shm). C'est le pere qui la crée (avec shmget).

    Puis chaque processus peut lire/ecrire dans cette zone (regarde man shmop).

    Pour eviter les probleme d'acces concurrent, tu fais passer tous les acces à cette zone par un semaphore unique (man semget / semop, ou alors les semaphores POSIX, man 7 sem_overview). Par exemple, les acces seront du genre :

    sem_wait
    READ or WRITE
    sem_post

    Voila, c'est super vague, mais je sais pas trop ce que tu cherches à faire. Il me semble aussi que n'importe quel bouquin/tutorial sur la programmation système unix explique toutes ces notions en détail.
    • [^] # Re: man IPC

      Posté par  . Évalué à 2.

      En fait, je cherche à réaliser un jeu de parcours (jeu de l'oie) jouable en réseau: le serveur accueille plusieurs clients (joueurs) qui peuvent créer une partie ou en rejoindre une, chaque partie pouvant être sauvegardée pour être rejouée plus tard. J'ai donc utilisé un tube pour communiquer à chaque fork() un pointeur sur le tableau de données en mémoire préalablement initialisé. Après une semaine d'acharnement, un collègue m'a expliqué hier que le principe de fonctionnement de linux ne permet pas ce genre d'opération via l'utilisation de pointeurs... Voici donc la dernière version en date du code en question:
      [CODE C]
      ...
       
      char data[1000][2048];
       
      int main() {
       
      	...
       
      	if(pipe(tube)==-1) {
      		perror("failed");
      	}
       
      	...
       
      	strcpy(data[0],"test");
       
      	...
       
      	switch (pid=fork()) {
      		case -1: perror("failed");
      		case 0: child();
      		default: parent();
      	}
       
      }
       
      void child() { // fils
      	close(tube[1]);
      	if (read(tube[0],&data,2048)<0) {
      		write(newsock,"failed",256);
      	}
      	*pdata = &data;
      	close(tube[0]);
      	write(newsock,pdata,256); // renvoie "test1" au client
      	read(newsock,data[0],256); // réceptionne une saisie du client (exemple "test2")
      	write(newsock,data[0],256); // renvoie les données au client (exemple "test2")
       
       
      	// après avoir lancé un client qui a renseigné ses données,
              //  "test1" s'affiche chez les nouveaux clients au lieu de par exemple "test2"...
      }
       
      void parent() { // père
      	strcpy(data[0],"test1");
      	close(tube[0]);
      	write(tube[1];&data,2048);
      	close(tube[1]);
       
      }
       
      ...
      [/CODE C]
      
      L'idée fut que chaque ligne de ce tableau représente une concaténation des données d'une partie et que la première entrée (data[0]) face office de pseudo sémaphore: échec cuisant en soit ^_^ Il me reste une semaine de nuits blanches pour réaliser ce projet qui me peine dans sa réalisation. Merci man IPC mais, bien que commençant enfin à avoir une vague idée de comment faire, ce n'est pas encore gagné d'avance...
    • [^] # Re: man IPC

      Posté par  . Évalué à 1.

      Autant pour moi, je voulais dire Castorpilot et non "man IPC"... -_-

      Les nuits sont courtes et la pause déjeuné se fait attendre ^_^
      • [^] # Re: man IPC

        Posté par  . Évalué à 3.

        Je vois un petit peu mieux de quoi il s'agit. Au risque de dire un truc bete, pourquoi ne pas utiliser des threads au lieu de forker ?
        L'avantage, c'est que les threads partagent la memoire, et que tu pourras utiliser ton tableau commun, contrairement au processus qui ont chacuns leur zone mémoire séparée, et donc les pointeurs de l'un ne sont pas valides chez l'autre.
        Il faut quand meme faire gaffe aux acces concurrents, avec des semaphores (sem_wait et sem_post autour des acces).
        • [^] # Re: man IPC

          Posté par  . Évalué à 2.

          J'ai déjà songé aux threads pour solutionner ma problématique, mais je me suis fixé comme contrainte l'usage du forker afin de satisfaire au mieux ma curiosité sur la communication inter-processus. Même si dans l'application cela reste assez laborieux pour le moment, je ne désespère pas pour autant ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.