segment memoire partagee, thread, ou autre?

Salut,

je suis en train de faire un petit serveur de variables d environnment (protocole TCP/IP).

du fait que j utilise ce protocole, mon serveur principal cree un fils( a l aide de fork) pour
chaque client qui se connecte.
chaque fils herite de l environnment de son pere.

le probleme est que, comme chacun sait, chaque processus est un espace clos avec
son propre environnement.
=> si j ai mon client 1 qui fait un setenv("HOME", "toto",1),
et que mon client 2 fait un getenv("HOME"), le client 2 ne recupere pas "toto".

Le but est donc d arriver a ce que tous les processus partagent le meme environnement.

J avais donc pensé user d un segment de memoire partagé, et de me passer des
fonctions getenv et setenv (et utiliser mes propres fonctions de hachage).

Ou encore de me servir de threads.

Mais bon, pour un petit serveur comme celui-la, ca me parait legerement disproportionne...

Je voulais donc savoir si vous aviez des idees de solutions plus simple, avant que je ne
me jette corps et ame dans l une de ces deux solutions... :wink:

Merci!

++
Pouic

Il me semble que avec les threads tu n'aurais pas ce probléme puisque chaque thread attaché a un process utilise les memes ressources donc var env ca doit etre pareil.

Oui, c est ce que je pense aussi.

Mais je voulais savoir s il existait un moyen autre que les threads ou les segments
memoires partages pour que differents processus aient le meme environnment (genre, en
utilisant fork, et en passant un pointeur sur l environnement, quelque chose comme ca...)

M enfin bon, je pense que je vais me rabattre sur les threads....

Mais si quelqu un a une idee, je suis toujours preneur!

++
Pouic

les sessions peut etre

Citation:

---

Envoyé par hegros

les sessions peut etre

---

:?:

comment ca?

Dans ton cas, la meilleure des solutions est d'utiliser les threads. Cependant, un thread peut entrainer le plantage de tous les autres donc il faut faire attention à la qualité de ta programmation. L'intérêt d'avoir des process différents est justement de ne planter qu'un seul process s'il y a un problème.
Pour tes partages de données, si tu utilises les threads, n'oublie pas d'utiliser des mutex pour les accès concurrents.

Sinon, tu peux aussi partager des données entre des processus, mais c'est très lié à l'OS sur lequel tu veux déployer ton soft. Ainsi, sous Linux, tu pourras réserver une partie de mémoire du kernel afin de partager des données. C'est ce que fait la version de mysql pour cet OS par exemple. Par contre, sous un BSD comme MacOS X, tu ne pourras pas toucher à la mémoire du kernel, ou alors, c'est beaucoup plus complexe, dans ce cas, il est conseillé d'utiliser le système de message de l'OS. Dans le dernier cas cité, tu pourras utiliser le système de message du noyau Mach.

Si tu veux faire un code multiplateforme, utilise les pthreads.

Pour faire très simple, un Thread est un processus dans un processus (notion de père et fil).

Pour exemple, un système multitâche créé un processus par application.

Si le développeur d'une application veut créer un processus. Il va être assez difficile de gérer les accès avec les autres applications. Surtout si ce n'est pas lui qui les a programmés. Donc on a créé une sur couche que l'on a appelé le Thread.

Si tu as compris comment marche un processus, tu n'auras aucun problème à utiliser les Thread.

Après, tu as des couches spécialisées qui peuvent englober un ou plusieurs Thread. Les sessions en sont probablement une.

Normalement le processus fils recupere un copie due l'environnement du pere, donc normalement ce que tu fais dois marcher a moins que tu ne fasse le setenv après avoir crée ton fils...

si ce que tu cherches ce sont les methodes de communications inter-processus (ipc)
il y a :
les signaux (primitif)
les messages queues
les segments de mémoire partagés
le pipes.
les semaphores

Citation:

---

Envoyé par olivic

Pour faire très simple, un Thread est un processus dans un processus (notion de père et fil).

---

La notion de père et fils n'existe que dans un fork, ou on a deux processus bien distincts.

Je n'expliquerais pas le thread de la même manière.
Un processus est une zone mémoire protégée (sous les OS récents ou les UNIX) dans lequel s'éxécute un ensemble de commande.
Dans ce processus, par défaut, il y a un thread. C'est à dire une séquence de traitement.
Cependant, le programmeur peut décider de lancer plusieures séquences de traitement paralèlle au sein de ce processus.

Les threads sont répartis sur un ou plusieurs processeurs et dans un ordre déterminé par l'ordonanceur du noyau. Celui-ci donne plus ou moins de temps à tel ou tel thread en fonction de sa priorité. Comme chaque processus a au moins un thread, les processus sont répartis eux aussi de manière indépendante sur les différent processeurs et dans un ordre donné par le micro noyau. Cet ordre est complètement chaotique, on ne peut pas vraiment prévoir comment vont être ordonancer les threads. C'est pourquoi il est important de protéger ses données des accès concurrents de lecteure/écriture. On peut aussi utiliser des opérations atomiques (une instruction processeur) afin de synchroniser les threads.

:D

Merci a tous!

C est donc bien ce que je pensais: il n y a pas de solution plus simple... :cry: :lol:
=> je vais donc utiliser les threads. (meme si je trouve ca un peu exageré pour ce que j ai a faire... mais, bon, j ai l impression de ne pas pouvoir faire autrement :wink: )

++
Pouic