fork() ? - C - Programmation
Marsh Posté le 31-03-2004 à 22:48:09
google... --> http://cui.unige.ch/~oriol/Teachin [...] de127.html
Marsh Posté le 31-03-2004 à 22:57:44
Process ID. C'est juste un numéro qui identifie un processus.
Marsh Posté le 31-03-2004 à 23:21:11
hmmm j ai du mal a saisir la,que fait le programme suivant par exemple ?:
main() {
int ret;
int a=33;
if (fork()==0) {
a++;
if (fork() == 0) a++;
if (fork() == 0) a++;
printf("a = %d\n",a);
exit(0);
}
wait(&ret);
printf("a=%d,ret=%d\n",a,WEXITSTATUS(ret));
}
trouvé je ne sais plus sur quel site, et au passage l'instruction WEXITSTATUS() c'est quoi ???
désolé désolé pour toutes ces questions ...
merci encore.
Marsh Posté le 31-03-2004 à 23:28:03
en fait si je comprends bien : fork() renvoi 0 si il est le processus pere et le numero du processus si il est fils, et le processus cré démarre au niveau du fork() ou c est un processus qui reprends tout le programme des le debut ?
Marsh Posté le 31-03-2004 à 23:39:06
C'est presque ça : fork() renvoie 0 pour le fils et le pid du fils pour le père.
Et effectivement, les 2 processus continuent l'exécution au même endroit.
Marsh Posté le 01-04-2004 à 00:01:36
patastronch a écrit : en fait si je comprends bien : fork() renvoi 0 si il est le processus pere et le numero du processus si il est fils, et le processus cré démarre au niveau du fork() ou c est un processus qui reprends tout le programme des le debut ? |
C'est un nouveau processus, qui continue l'exécution du même programme, au même point (l'appel de la fonction fork()).
C'est assez compliqué à comprendre
Au début, tu as un programme qui s'exécute. Lorsqu'il appelle la fonction, il est "copié", et le retour de cette fonction fork() se fait dans 2 programmes identiques mais indépendants.
Identiques ? Pas tout à fait : la seule différence qui existe, c'est le code de retour de cette fonction (0 pour le processus fils, le pid du fils crée pour le père).
Marsh Posté le 01-04-2004 à 05:03:45
Puis faudrait préciser aussi que les deux processus (père et fils) ne partagent pas leur données. Dans ton exemple (c'est quoi d'ailleurs ces instructions en dehors de main ?) quand un process fait a++, ça ne modifie pas le a du père.
PS : à l'inverse des threads...
Marsh Posté le 01-04-2004 à 09:12:51
FORK(2) Manuel du programmeur Linux |
Je crois que c'est assez clair !
Marsh Posté le 01-04-2004 à 14:45:57
ReplyMarsh Posté le 01-04-2004 à 15:01:16
je n'aime pas beaucoup ce smiley
si tu a un truc désagreable à dire, dit le avec des mots au moins
il me semble que le fait que fork n'existe pas sous windows est un point important
evidement tout le monde le sait, disons tous ceux qui connaissent fork(), mais justement CE TOPIC est destiné à un mec qui ne connait PAS fork, donc le detail à son importance
Marsh Posté le 01-04-2004 à 17:39:56
Tu as peut-être raison oui. Mais ça me paraissait couler de source, vu que la gestion des process sous nix est complètement différente de Windows (parent, etc...)
Marsh Posté le 01-04-2004 à 20:29:25
Dans quel cas on utilise fork dans la pratique? Je ne vois pas trop l'avantage par rapport au multithread, au contraire.
Marsh Posté le 01-04-2004 à 20:30:32
JagStang a écrit : la gestion des process sous nix est complètement différente de Windows |
C'est justement pour ca qu'il faut préciser ou sont les différences!
Marsh Posté le 01-04-2004 à 21:47:50
le fork a ses avantages et ses inconviénients.
Déjà evidement il existe pas sous tous les OS. windows fait uniquement du multithread. En pratique tu peux lancer de vrais process sous windows mais il commenceront tous au début du prog, et si tu lance de process ils prendront deux fois plus de RAM. Sur Unix le fork donne l'impression qu'il duplique le process: les deux process ont un pid differents, sont indpendant au niveau des variables, mais en réalité rien n'est dupliqué des le depart: seules les zones memoires modifiées sont dupliquées à al volé (cpoy on write). dans la pratique ca ne change rien pour le programmeur, mais ca economise un max de memoire puisque toutes les parties communes (code, bibliotheques, variables non ecrites,...) sont partagées.
Par rapport à du multithread le fork est (censé etre) plus leger et donc plus rapide.
EDIT: erreur de dyslexie mentale: il fallait lire (ou plutot il aurait fallu ecrire) :
Par rapport à du fork le multithread est (censé etre) plus leger et donc plus rapide.
En réalité c'est pas evident du tout, et ca depend notamment des plateformes (Solaris gere tres mal les process par exemple, d'ou Java et le multithreading à outrance). en réalit" le surcout se situ surtout à la destruction du process, et un peu à sa creation (mais presque aucune copie de memoire n'est faite à ce moment, puisqu'il y a le copy on write). Pen,dant l'execution le fait de scheduler des process ou des thread revient au meme pour un OS comme Linux par exemple.
Alors evidement le multithread permet de partager des variables entre ses thread, contrairement au process (quoique on peu utiliser des trucs genre socket, mmap, etc...), mais en fait perso je ne trouve pasque ce soti un avantage et ca va en tous cas à l'encontre des principes d'encapsulation/modularité/etc... et en plus avec les thread on pert completement l'aspect independance: si une thread plante tout plante, alors que si un process plante les autres continuent (sauf si l'os plante evidement).
Evidements on a parfois envie de faires plusieurs choses en meme temps en partagant beaucoup de données, mais dans ce cas je trouve plsu avantageux de tous points de vue de faire qq d'asynchrone, et en plus ca a l'avantage d'etre encore beaucoup plus rapide que des thread (aucun changement de contexte)
Marsh Posté le 02-04-2004 à 05:35:24
A quoi sert fork ? Ben sans fork tu aurais un seul process Sous Unix il y a un process initial, init, et tous les autres process sont des forks d'init, ou des forks des forks d'init... Enfin des descendants d'init. C'est comme ça qu'un process lance un autre process : il fork, et le code du fils (dans le if (0 == fork())) fait un execve. Le fork duplique le process qui fork, le execve fait executer un autre code au processus fils. C'est comme ca que tous les process sont crées.
D'ailleurs si dans ton code tu fais des system(), des popen()... Et bien ces fonctions font des forks « behind the scene ».
Ensuite tu peux aussi faire des forks sans execve derrière, juste pour executer deux parties de programme en parallèle. Exactement comme tu ferais avec des threads. Thread ou process, tout depend de ce que tu veux faire. En gros avec des process tu sépare tout et tu doit faire des effort pour communiquer (semaphores & shared memory...). Avec des threads tu partage tout et tu doit faire des efforts pour pas qu'il se marchent sur les pieds (mutex & conditions...). M'enfin c'est clair que si ce n'est pas pour aller executer un autre programme, les threads seront en général plus adaptés.
Marsh Posté le 02-04-2004 à 10:37:55
merci Taz (bien que je ne sois pas certain qu'il ne s'aggisse d'une moquerie, vu notamment les 15000 fautes qui innondent mon post que j'aurais au moins du relire!)
Je rajoute une petite note sur le copy on write: ca marche bien pour les langages dans lesquels on maitrise vraiment l'allocation de sa memoire, comme le C (ou disons suffisament), mais c'est un peu plus chaotique dans les langages de script par exemple. en effet quand une variable (ou plus généralement une zone memoire) est modifiée c'est toute la (ou les) page memoire de 4ko qui la contenait qui est copiée (la zone memoire du pere est mise en write only, et toute tentatives d'ecriture, meme venant du pere, entrainent une faute et la copie à la volée), et si les variables sont eparses ou que l'on réinitialise des variables avec la meme valeur, on a des copies inutiles. Dans ce cas il faut "penser" son prog des le depart dans cet objectif (mais c'est egalement le cas, et meme encore plus, pour les threads. la c'est plus une optimisation)
Par exemple dans des scripts Perl que j'utilise et qui occupent 15Mo au départ, les fils ne partagent "que" 9Mo environ (apres avoir tourné un peu), en partie à cause de certains modules qui prennent un malin plaisir à réinitialiser des variables pour rien...
a ce propos, j'avais vu un petit prog appelé mergemem, et qui etait censé scanner la memoire et repartager les zones memoires identiques (meme si elle viennent de deux process totalement independants). Malheureusement il semble ne plus avoir été mis à jour depuis longtemps, et il fallait patcher le noyau de Linux (prévu pour le noyau 2.2...) donc j'ai pas essayé (je suis pas un vrai linuxien, j'ai trop peur de tout casser mon joli 2.6 à peine installé). Vous connaissez des equivalents plus actuels?
Marsh Posté le 02-04-2004 à 11:08:44
non, je crois que tu t'es gouré là
ou t'as pas la même définition de fortune
Marsh Posté le 02-04-2004 à 11:25:12
alors tant mieux. on est jamais à l'abri d'un deuxieme degres kisscool par les temps qui courent
Marsh Posté le 02-04-2004 à 11:28:01
tu t'attendais quand meme pas a une critique constructive de la part de Taz ?
lui qui est si peu imbu de sa personne, si il avait des remarques a faire, tu penses bien qu'il les ferait, il ne se limiterait pas a faire des posts avec juste "c'est nul" "t'es con" "va apprendre a coder"
non, lui son style, c'est d'aider vraiment les gens en leur expliquant leurs erreurs
Marsh Posté le 02-04-2004 à 11:46:27
c'est nul, t'es con, va apprendre à coder...
non mais sérieusement, tu te sens bien pospos ?
« Par rapport à du multithread le fork est (censé etre) plus leger et donc plus rapide. » celle là je vais l'encadrer.
Marsh Posté le 02-04-2004 à 12:27:37
ok j'ai inversé mes pinceaux sur celle la, je voulais dire exactement l'inverse (mais du reste ca se comprend normalement si on lit le reste)
je vais editer mon post
Bon, alors explique moi ce qui te chargrine Taz
Marsh Posté le 02-04-2004 à 12:33:08
tout ton poste n'est que contradiction, à te lire, on comprends que heureusement que fork a été inventé pour pallier au défaillances des threads... question subsidiaire : tu ferais bien de documenter histoire de savoir ce qui fait touner les threads
Marsh Posté le 02-04-2004 à 12:37:16
Mis à part l'inversion que tu a souligner, le reste est cohérant, et est le résultat de mon experience dans des situations réelles
Mais tu peux aussi nous parler de la tienne (bouquins? TP? je suis certainq ue tu est le premier de ta classe en TP)
Marsh Posté le 03-04-2004 à 14:12:00
Alors Taz, j'attends toujours tes arguments!
Mis à part cette etourderie qui semble t'avoir fait beaucoup rire (maintenant qu'on m'a fait decrouvrire ce que signifiait le terme "fortune" dans la bouche d'un neuneu de l'info), j'aimerais bien savoir ce qui pourrait deranger un fin esthete comme toi dans mon post.
Taz, à vrai dire je te connais sans doute moins que ce qui passent leur vie à arpenter ce forum à grands coups de smileys et de "roulezzzz", mais j'en ai vu assez pour m'apercevoir à kel point tu etais imbu de ta personnne. J'airais bien d'autre choses à te dire, mais je ne le ferais pas par respect pour ceux qui considerent encore ce forum comme un lieu d'echange et d'entre aide et non un lieu de glande ultra-communautaire pathétique. Mais j'adorerais te rencontrer pour pouvoir te mettre les points sur les i (et dans ta gueule)
mais pour l'instant parlons de fork() si tu le veux bien
Marsh Posté le 03-04-2004 à 16:59:07
Citation : |
Calmons-nous... Taz est un peu "vif", mais ses conseils sur des points précis sont souvent précieux. Et toi ? Qu'as-tu apporté à ce "lieu d'échange"
Marsh Posté le 03-04-2004 à 17:15:19
moi je contribu à la rubrique Perl, et dans d'autres parfois. Je ne pense pas avoir jamais été désagréable avec qq1 qui demandait conseil, et ce que je deteste par dessus tout c'est l'esprit communautaire et fermé qui reigne dans certains coins de ce forum (et de l'info en général).
Je trouve etrange que certaines personne se permettent des chose sur internet que jamais elles n'oserait en ayant la personne en face.
Je suis modérateur sur un autre forum (qui ne traite pas d'informatique) et nous essayons d'instaurer un climat d'echange et une ambiance acceuillante pour les "newbies" (comme vous dites). Nous essayons egalement de pereniser les connaissances et les informations (un peu à la maniere d'un wikki) afin de rediriger le debutant qui pose une question connue sans pour autant l'insulter.
Je viens ici car c'est le forum info le plus actif à ma connaissance, et que j'ai envi de contribuer à la section Perl, mais je trouve assez désagréable de lire les reponses de Taz ou de se voir soit meme insulté par cet espece d'animal ridicule qui porte bien son nom. Je l'imagine grand et maigre, encore boutonneux, et abonné à toutes sortes de magazines à pinguin. Je l'imagine faible dans sa tete et dans son corps, argneux et revenchar, complexé. Si ce n'est pas le cas je l'invite à me le pouver en acceptant un combat loyal qui verra rapidement sa figure s'applatir sur les briques lisses et blanches du couloir de métro de son choix. Mais cela n'a rien à voir avec le forum, comme tu l'a fait remarquer, et je suis certain que vous saurez prendre cette phrase avec le meme humour que les insultes de Taz...
Marsh Posté le 03-04-2004 à 17:23:33
pospos a écrit : moi je contribu à la rubrique Perl, et dans d'autres parfois. Je ne pense pas avoir jamais été désagréable avec qq1 qui demandait conseil, et ce que je deteste par dessus tout c'est l'esprit communautaire et fermé qui reigne dans certains coins de ce forum (et de l'info en général). |
Là tu vas un peu loin avec tes menaces... Votre règlement de compte n'intéresse personne. Pour ton info, Taz ne ressemble pas à ton descriptif (désolé...)
Marsh Posté le 03-04-2004 à 17:27:54
pospos> tu imagines mal, et tu es très premier degré, ce qui est un défaut par ici. Il est assez vif mais il a déjà dit plein de fois qu'il n'était pas aggressif dans ses posts.
Ah encore une chose: il est bien foutu le Taz physiquement ( )
Marsh Posté le 03-04-2004 à 17:31:42
Et bien moi aussi je le dit alors: je ne suis pas agressif dans mes posts. La, comme ca, c'est facile.
Marsh Posté le 03-04-2004 à 17:36:19
pospos, en tant que contributeur de la rubrique Perl, je ne peux que te remercier de venir ici.
Malgré ses reflexions dures et agressives, Taz reste un contributeur irremplacable sur ce forum (C/C++, Python et autres), il repond toujours lorsqu'il connait la reponse. Je veux bien croire que ses methodes ne sont pas les meilleurs au niveau communication mais parlez violence pour ça, enfin voilà quoi...
Marsh Posté le 03-04-2004 à 17:43:30
je suis sûr que Harko va venir nous pondre un pavé
Marsh Posté le 03-04-2004 à 17:46:05
il est a Pau ce WE, il devait retrouver taz pour parler C++ justement...
Marsh Posté le 03-04-2004 à 17:48:06
sauf que Harko n'allait pas à Pau (il l'a dit sur blabla@prog)
Marsh Posté le 03-04-2004 à 17:51:07
drasche a écrit : sauf que Harko n'allait pas à Pau (il l'a dit sur blabla@prog) |
ah, j'ai loupé cette partie
Marsh Posté le 03-04-2004 à 18:04:21
drasche a écrit : sauf que Harko n'allait pas à Pau (il l'a dit sur blabla@prog) |
merde, je me suis levé trop tard, j'arrive pas à le trouver
Marsh Posté le 03-04-2004 à 18:11:50
pospos a écrit : |
Au pif-ô-mètre, je parierais plutôt sur :
1°) une vie sexuelle assez pauvre
2°) une rigueur certaine qu'il s'impose
Dans le premier cas, le lien avec l'agressivité est quasi-évident. Dans le deuxième, c'est un poil plus compliqué. Disons, pour faire simple, que la quête de la perfection astreint à des souffrances inexpugnables. Or il se trouve que personne n'aime souffrir tout seul, ce qui nous amène à ce qui pourrait être sa devise : "marche (vers la perfection) ou (je te) crève". C'est un jeu rigolo mais mon petit doigt me dit qu'il n'aime pas trop l'inversion des rôles. Bref, de ce que j'en pense, le mécanisme à l'oeuvre là-dessous se nomme "projection". Il s'agit de projeter sa propre culpabilité refoulée (en l'occurrence, ne pas être parfait) sur les autres (encore plus imparfaits) afin de rendre cette culpabilité supportable. C'est très fréquent chez les personnes qui n'ont aucun génie mais qui n'en sont pas moins extrêmement intelligentes. En clair, il n'y a là rien de bien extraordinaire. Pour conclure, ce serait amusant d'analyser les interactions que cela pourrait avoir sur sa vie sentimentale et sexuelle. Autrement dit, que raconte taz pour séduire une femme?
Marsh Posté le 31-03-2004 à 22:36:30
Bon je debute en c, et je ne comprendspas trop ce que fait la fonction fork() ...
VOila si quelqu un pouvait m'expliquer ce qu'elle fait exactement ..
merci d'avance pour vos reponses