Discussion :

[nek_kro_kvlt]

Bonjour à tous, je cherche un moyen de créer un processus fils et de partager certaines, ou toutes les variables entre le père et le fils. Voila, le principe est que j'ai une classe se chargeant d'envoyer des données via un socket, et je voudrais faire un thread qui se chargerai de les recevoir, et qui, suite à certaines données reçue, pourrait intéragir avec l'instance de ma classe pour modifier l'envoi des données (vitesse, taille etc...).
Ce que j'ai compris, c'est que fork copie les variables, donc pas possible ?
Sinon, je peux utiliser un pipe, mais n'y a t-il pas une solution plus simple ?

[Ma7moo7]

Je ne cerne pas trop ton problème,
Tu peux implémenter des threads -coté émetteur- qui partagent les mêmes ressources.. penser à les synchroniser avec les sémaphores et conditions..
et selon les réponses reçues, bloquer certains threads et en laisser d'autres..
Je ne sais pas si ça répond vraiment à ta question car je n'ai pas vraiment compris ton souci

[nek_kro_kvlt]

En fait je bosse avec des raw socket, et j'ai une classe qui envoi des paquets d'une certaine taille, à une certaine vitesse. Je veux un thread qui analyse les données reçue sur le réseau, et traite ces données, puis en fonction de ça, interagisse avec la classe d'émission afin de modifier la taille et la vitesse d'envoi. J'ai deux fonctions dans cette classe (set_mtu et set_framerate) pour faire cela, il faut juste que mon second thread y accède. L'instance de cette classe d'envoi peut être dans un thread séparé ou dans le porgramme principal

[Sve@r]

Bonjour à tous, je cherche un moyen de créer un processus fils et de partager certaines, ou toutes les variables entre le père et le fils. Voila, le principe est que j'ai une classe se chargeant d'envoyer des données via un socket, et je voudrais faire un thread qui se chargerai de les recevoir, et qui, suite à certaines données reçue, pourrait intéragir avec l'instance de ma classe pour modifier l'envoi des données (vitesse, taille etc...).
Ce que j'ai compris, c'est que fork copie les variables, donc pas possible ?
Sinon, je peux utiliser un pipe, mais n'y a t-il pas une solution plus simple ?

Il y a indépendance totale entre processus. Lorsque le fils est créé, il reçoit une copie de toutes les variables du père mais ensuite ces variables copiées deviennent autonomes pendant que le père garde les siennes.

Une solution plus facile qu'un pipe peut être les IPCS (msq, shm, sem) et plus particulièrement la share mémory (shm)
1) ton père crée une shm avec id=shmget(clef, IPC_CREAT)
2) il attache sa shm à un pointeur local avec pt=shmat(id)
3) son fils récupère l'identifiant de la shm avec id=shmget(clef)
4) il attache la shm à un pointeur local pt=shmat()

Ensuite, comme chacun a accès à la shm via son propre pointeur et que cette shm est unique, les 2 processus ont accès à la même zone. Ils peuvent donc y copier ou récupérer des infos via memcpy()

Généralement, quand on utilise une shm on y associe un sémaphore (semget()) pour protéger la zone lorsqu'on veut y écrire (ça évite que celui qui veut lire lise des valeurs qui sont en train d'être modifiées)...

PS: Tu as utilisé le mot "thread". La gestion des thread n'est pas la même que celle d'un processus. Notamment les thread partagent leurs data donc si tu utilises des thread, c'est plus la même chose...

[nek_kro_kvlt]

Il y a indépendance totale entre processus. Lorsque le fils est créé, il reçoit une copie de toutes les variables du père mais ensuite ces variables copiées deviennent autonomes pendant que le père garde les siennes.

Une solution plus facile qu'un pipe peut être les IPCS (msq, shm, sem) et plus particulièrement la share mémory (shm)
1) ton père crée une shm avec id=shmget(clef, IPC_CREAT)
2) il attache sa shm à un pointeur local avec pt=shmat(id)
3) son fils récupère l'identifiant de la shm avec id=shmget(clef)
4) il attache la shm à un pointeur local pt=shmat()

Ensuite, comme chacun a accès à la shm via son propre pointeur et que cette shm est unique, les 2 processus ont accès à la même zone. Ils peuvent donc y copier ou récupérer des infos via memcpy()

Généralement, quand on utilise une shm on y associe un sémaphore (semget()) pour protéger la zone lorsqu'on veut y écrire (ça évite que celui qui veut lire lise des valeurs qui sont en train d'être modifiées)...

PS: Tu as utilisé le mot "thread". La gestion des thread n'est pas la même que celle d'un processus. Notamment les thread partagent leurs data donc si tu utilises des thread, c'est plus la même chose...

Merci pour cette réponse clair, la fonction fork() ne fait pas de thread ? Par contre j'ai regardé effectivement, avec les pthread, peut être cela serait plus simple, en passant un pointer sur mon instance lors de la création du thread ?

[Ubiquité]

Merci pour cette réponse clair, la fonction fork() ne fait pas de thread ?

Non, un processus (fils). Un thread c'est un processus léger.

Par contre j'ai regardé effectivement, avec les pthread, peut être cela serait plus simple, en passant un pointer sur mon instance lors de la création du thread ?

Plus simple et probablement plus adapté.

[nek_kro_kvlt]

Oki, je vais tester ça alors
Merci

[Sve@r]

Merci pour cette réponse clair, la fonction fork() ne fait pas de thread ?

Hé non. N'oublions pas que la notion de programmation parallèle était implantée dès l'origine d'Unix en 1970 et que Linux reprend les mêmes concepts.
Et les thread sont apparus bien plus tard avec Windows et on voit bien les problèmes de sécurité que cela entraine (notamment avec les virus qui n'hésitent pas à attaquer des zones mémoires d'autres programmes)

Par contre j'ai regardé effectivement, avec les pthread, peut être cela serait plus simple, en passant un pointer sur mon instance lors de la création du thread ?

A toi de voir. Travailler avec des processus distincts offre une grande sécurité mais se paye par une programmation plus délicate. Travailler avec des thread c'est l'inverse mais ça peut se justifier si la sécurité n'est pas primordiale
Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers. (Herbert Mayer).