Bon, je maitrise pas trop encore la gestion des thread et des processus, mais je me pose une question.
Assez souvent en C on cree des processus fils avec fork(), par ex sous la forme
pid = fork()
if(pid==0) { processus fils qui prend du tps...}
 
Tout ca c'est assez clair et ca parait tres bien, mais j'ai vu aussi qu'il y a la classe pthread qui permet elle de creer des threads (donc plus "leger" a l'execution normalement) et tout...
 
ALors dans quel cas on utilise koi? comment savoir si c mieux un fork ou la creation d'une thread en fonction de ce qy'on doit faire ?
 
Merci pour vos reponses

Les threads c'est pratique, tu peux utiliser des variables globales
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
EDIT : sans mutex bien entendu
Pour répondre à ta question, les threads sont plus légers se partagent le même espace d'adressage. A moins de vouloir éviter de partager l'espace d'adressage (pour des raisons de sécurité), je ne vois pas trop l'intérêt de forker. Enfin, c'est juste mon avis, et je suis tout sauf un expert sur la question

Au commencement y'avait les processus, et fork était là faute de mieux. Puis vinrent les thread, et fork resta utilisé par fainéantise des programmeurs, et des profs aussi.
Les thread c'est bon mangez en!

ouais mais les threads ce n'est quand même pas évident! perso, bon c'est vrai que je débute dans la prog, dès que je px j'utilise un petit timer qui est fait en 2 lignes =). je développe surtout pour des appli qui fonctionne ac du matériel tel que des balances ou des douchettes, dc je px éviter le multitache. ms bon, faudra bien que je m'y mette un jour :-(

ok, donc si on resume, vieut vaut utiliser les threads parce que :
 - un gros avantage : bcp plus leger (donc chgt de contexte et tout vachement rapide)
 - pas vraiment d'inconvenients...
 
ca parait correct ?? Vive les threads alors !  

y dit qu'il voit pas le rapport entre des "des balances ou des douchettes" et les fork()    ...
 
Ha si je crois avoir compris, enfait c'est implicite comme raisonnement:
 

 
héhé des tube && des pipes, ca C pour les douchettes    
 
===========ok ok je suis deja dehors=======>[ ]

moi j'ai rien compris à ce qu'il a dit.

moi non plus  

Il développe des systèmes embarqués.
 
 
(ce qui est en soi un label de qualité, soit dit en passant ).

 
Mais bien sur. T'en as d'autres des comme ca ?

ouai :
les thread ne sont pas utilisés par fainéantise des programmeurs et des profs aussi.
Tu m'as l'air calé sur la question, alors peut être vas-tu enfin me faire comprendre pourquoi on utilise encore fork aujourd'hui ?

Une chose est sur c'est que le fork reste ULTRA simple à utiliser meme si toute la gestion des IPC est un peu lourde.

C'est exactement ce que dit HelloWorld

Et créer un thread c'est ultra compliqué ?

c ptetre la fermeture du programme, sans fracasser tout les threads secondaires qui est un peu plus problématique ?

si les threads sont bien codés ca ne pose aucun probleme

En quoi c'est différent avec les processus ?

tous les processus fils d'un processus sont détruits qd le père l'est ?
(je connais pas trop la hierarchie de processus unix)

Ca dépend des UNIX...

HelloWorld : est-ce que tu réalises que sans fork() tu n'aurais qu'un seul processus, init ? Lancer un programe, c'est faire un fork/exec.
 
Sinon non, les processus fils ne sont pas détruits quand le père l'est. Ils sont ratachés à init.

Est-ce que tu réalises qu'on parle de l'utilisation du multiprocess là où le multithread convienfrait mieux ?
Je critique pas l'utilisation de fork pour créer un process, mais la création d'un process (au moyen de fork) là où un thread serait mieux adapté.

A quoi sert la commande nohup alors ?

 
C'est surtout que les threads partagent le même espace d'adressage, c'est là que réside en pratique la différence fondamentale / process -> pas besoin de communication interprocess, mais par contre, il faut gérer des mutex et éviter qu'ils soient bloquants.
 
http://www.codeproject.com/threads/

Eviter qu'un mutex soit bloquant, tu fais pas grand chose avec alors
Même pour la synchronisation c'est plus performant avec les thread grâce aux sections critiques.
http://support.microsoft.com/defau [...] -us;105678

Oui, je voulais dire en blocage mutuel oeuf corse.
Et comme tu dis, les threads c'est nettement plus performant.

www.boost.org
 
BOOST::THREAD et c fini.

vas dire ça à un compilo C. on n'est pas chez les c++ ici.

Savez-vous si on peut faire des sections critiques sous Linux et si oui comment ?

Avec LinuxThreads, par exemple.

En fait je cherche si y'a un équivalent de EnterCriticalSection.
http://msdn.microsoft.com/library/ [...] ection.asp
Il me semble qu'il y en a un depuis pas trop longtemps, mais je crois que ça porte un autre nom.

HelloWorld : comme son nom l'indique, nohup sert a bloquer les SIGHUP. Quand un process termine, un SIGHUP et un SIGCONT sont envoyés aux processus fils.
 
Donc non, terminer un processus ne détruit pas ses processus fils. Ca leur envoie seulement ces deux signaux, qu'ils sont libres de traiter comme ils l'entendent, y compris en terminant eux-même (ce qui est l'action par défaut de SIGHUP). S'ils en font autre chose, ils sont rattachés à init.

Dans le détail tu as raison, mais vu de haut c'est pareil : quand le père se termine le fils reçoit un signal qui par défaut (et donc la plupart du temps) provoque sa mort.
Résultat : quand le père meurt, ses fils aussi. C'est le comportement par défaut et j'aurais tendance à dire le comportement conseillé, vu qu'on laisse l'utilisateur choisir (=> nohup).
Mais j'aurais une question : est-ce que tous les UNIX se comportent ainsi ? Car je me souviens de tp de réseaux sous HP-UNIX où on nous gueulait dessus parce que y'avait plein de process zombi (tuer le serveur ne tuait pas les process clients).