Reprise du message précédent :

 
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?

DocMesBoules, tu me refais un post hors topic comme ca sur ce forum, et je te les ecrase a grand coup de lattes moderatrices!
 
J'aime pas toujours l'aggressivité de l'autre Tazfiole, mais faut reconnaitre que en general, il sait de quoi il cause l'animal, et je l'ai rarement vu pris en defaut sur un point technique.
 
A+,

Vi, Taz est un peu ours sur les bords, mais il aide tjs, même si la forme n'y est pas forcémment, et il est pleins de bon conseils, même avec les neuneux ... comme nous
Donc perso je préfère sa façon de s'exprimer

insistez pas trop quand meme, il va se lacher apres

Dites, les psychologues en herbe, vous faites vraiment pitié à lire...
Et pis proférer des menaces le cul sur son fauteuil c'est super comme truc
 
(je peux avoir ma psychanalyse aussi ?)

T'es qui toi ? un multi ?
 
Allez bonne nuit

Loupé
Ça fait même un bail que je suis inscrit ici, même si je poste pas souvent, mais ya des topics mieux que d'autres tu vois ;-)

justement. 170 messages en 2 ans c'est plus que du suspectage de multi.

Ben qu'est-ce que tu veux que je te dise, tu n'as que ma bonne foi
Mais si tu en décides ainsi ça ne me dérange pas outre mesure

dites, c'est ptet pas la peine d'en rajouter une couche hein

je voudrai qu'on m'éclaircisse sur un point du programme (j'essaye de le comprendre aussi)
Normallement, le main doit créer 4 processus :  
main() {
 int ret;
 int a=33;
 if (fork()==0) {                //le premier (A) je suis ok
  a++;
  if (fork() == 0) a++;           //le second (B),crée par A
  if (fork() == 0) a++;            // et la un troisième C mais crée par qui, comme ya pas de parenthèses je saisi pas bien!!
 
d'autre part, et si j'ai bien compris, le fork () renvoi le pid au père et une valeur nulle au fils. Donc comment ca se fait que le premier if puisse s'exécuter si le fork() revoi une valeur tout sauf nulle???
Merci de votre aide, je suis larguée!

Avec ton programme (disons que les 2 accolades se ferment après le code que tu as mis), le père crée 1 fils, qui crée à son tour 2 fils (des petits-fils, en quelque sorte )
 

Pour être plus précis, il faut le dire de cette manière : dans le fils, fork() renvoie une valeur nulle, et dans le père, une valeur non nulle (l'id du fils créé).
 
C'est ce qui est difficile à bien comprendre. Le fork() est appellé dans 1 processus, mais il y a 2 processus lorsque la fonction fork() se termine (avec un résultat différent dans chacun)

Salut à tous, désolé de remonter ce tout vieux topic mais j'ai aussi une question sur les fork(). Je comprends le fait de la duplication mémoire, et les valeurs renvoyées mais j'ai du mal à cerner ce que fait le fils, comment il le fait et ce que fait le père. Comment se passe l'exécution des différents codes ?
 
Voici un schéma du code que j'essaie de comprendre.
 

 
Je dois avouer que j'ai du mal à voir comment le fils exécute son code. Au niveau du fork() on va chaque fois créer un fils, ce fils va hériter de tout ce qu'il s'est passé plus haut mais on a dit qu'il exécute le même code que le père et ça je capte pas. Est-ce que le fils va aussi faire les bouts de code (*) et (**) ? Je suppose que non vu le exit(1) mais que fait ce exit(1), il tue le fils ou lui dit simplement "gamin t'as fini ton code là !" ? Est-ce que le père et les fils exécutent leur code chacun son tour ou bien "plic ploc" ?
 
merci de m'éclairer car je nage là  

 
Comme on l'a dit dans ce topic, lorsque le "fork" commence il n'y a qu'un seul processus mais à la fin de l'instruction, il y en a deux et pour chacun d'eux la valeur donnée par "fork" est différente
 
Voici un autre bout de code qui t'expliquera mieux (j'espère)

 
En ce qui concerne tes autres questions, l'instruction "exit" arrête un processus. Et les deux codes ne s'exécutent, au niveau atomique, pas réellement en parallèle. En fait, le processeur donne la main à l'un pui à l'autre puis au premier etc. Un peu comme au cinéma avec 24 images par secondes tu crois que l'action est linéaire alors qu'elle est saccadée. Là c'est pareil. Au final tu crois que les deux processus ont tourné en parallèle...

 
IMPECCABLE ! C'est exactement ce que je voulais savoir ! Ton exemple explique super bien comment les choses se passent et ta confirmation de l'exit me permet de bien comprendre comment mon programme se comporte.
 
J'ai cependant encore une toute dernière question : les deux processus exécutent leur code de quelle manière ? (d'abord tout le fils ou tout le père ou bien au hasard, une ligne du père puis du fils puis x lignes du père et puis y lignes du fils ?)
 
merci beaucoup !      
 
edit : grillé (tu as édité avant ma réponse )
 
encore merci

 
Je suppose que ARRETER ne signifie pas TUER ?
 
Bref le processus ne fait plus rien mais est tjrs en vie ou bien il est plus là ?
 

 
C'est un peu plus subtil que cela...
L'instruction "exit" tue le fils mais il ne meurt pas tout à fait. Il reste dans un état résiduel appelé "zombie" (comme dans les films) tant que le père n'est pas mis courant de sa mort.
Pour que le père prenne connaissance de la mort de son fils, il faut qu'il fasse un "wait(&status)"  (la variable "status" étant déclarée comme "int" ). A ce moment là, si le fils est "mort", la variable "status" se remplit avec un nombre indiquant la cause de la mort du fils.
Si le fils est mort par un "exit(n)", le nombre "n" est stocké dans le premier octet de "status" (octet de poid fort) et le second octet est mis à 0.
Si le fils est mort par un "kill(k)", le nombre "k" est stocké dans le second octet de "status" (octet de poid faible) et le premier octet reste indéterminé.
Le père peut donc récupérer et/ou tester ces valeurs "n" ou "k" en utilisant des décalages et masques, ou en utilisant des macro déjà écrites et qui font ça pour toi :
WIFEXITED(status) renvoie "vrai" si le fils est mort par "exit"
WIFSIGNALED(status) renvoie "vrai" si le fils est mort par "kill"
WEXITSTATUS(status) donne la valeur "n" du "exit(n)"
WTERMSIG(status) donne la valeur "k" du "kill(n)"
 
Si le fils n'est pas mort lorsque le père appelle "wait", l'instruction "wait" reste bloquée jusqu'à ce que le fils meure. On peut utiliser pour éviter cela la primitive "waidpid(pid, &status, WNOHANG)" où l'option "WNOHANG" demande de ne pas bloquer le "wait"...
 
Une petite astuce te permet de "forcer" l'un des deux processus à démarrer le premier (si tu en as besoin). Il te suffit de mettre un "sleep(1)" au début du code de l'autre...