Dites, on a besoin d'aide et on capte pas pourquoi ca déconne Taz va surement hurler "le code il est moche" , je l'en prie
 
Notre projet est un serveur web multithreadé avec support CGI.
 
Notre traitement CGI est simplifié : on file la requete intégrale http sur stdin du programme CGI et basta  ( pas de variables d'environnement a la apache et co ).
 
Donc l'architecture basique du serveur web :
-Un thread principal quié coute les requetes et les ajoute dans une liste chainée.
-X threads qui prennent en boucle ( avec force semaphores et compagnie) les "jobs" dans la liste chainée et les traitent.
 
On a pour consigne impérative de gérer les CGI avec exec ou consorts ( la je suis d'accord ) et de laisser le thread répondre a d'autres jobs sans avoir a attendre la fin d'un CGI.
 
Voici le bout de code que l'on utilise actuellement qui gère cela :
 

 
PRes2->nomappli contient l'executable a lancer ( perl dans notre cas), PRes2->nomFic le nom du fichier sur lequel executer perl, et Preq->Raw la requete brute a renvoyer au CGI, sc le socket en cours.
 
Bon, vous etes arrivé la, merci de votre patience et de votre compréhension.
 
Notre problème est simple :
-Si on mets un wait(0) dans le père, ca marche nickel, la réponse est renvoyée, et YAISS c'est cool, mais le père attends que le fils se termine.
-Si on mets pas de wait(0), le pere s'execute et continue son travail sans souci ( c'est un thread); mais le fils execute le prog perl correctement, envopie la réponse... et reste en processus Zombie dans ps, et surtout n'execute rien de ce qui se trouve sous l'execlp ...
 
Vous auriez une idée sur le pourquoi du comment de ce probleme ?
 
Merci énormément
 
PS : putain d'identation de merde

 
Je suis pas certain mais essaye avec waitpid et l'option WNOHANG
 
A+

fork() ne crée pas de threads mais des processus

salut je viens d essayer rapidement et le code derriere un execlp n est pas execute normalement( il est ecrase par le programme appele).
Maisje suis ptete pas dans le sujet...

bah c'est plutôt normal, un exec ça ecrase le code

t'as peut être surtout vraiment rien comprus

mettre du code apres le execlp/vp/etc équivaut à :
 
int fct()
{
 return 2;
 std::cout << "ahah\n";
}
 
le fork permet de dupliquer le programme en mémoire et le execlp remplace tout le code de la copie par le programme désiré.

j'ajouterais "man execl" pour plus de compréhension

Bon, OK, mais ca, limite, on s'en fout un peu ( vu que l'on doit gérer un nombre maximum de processus CGI s'executant ... ben... ).
 
Deja, dans l'architecture présente qui les gère pas, pourquoi si le pere ne fait pas de wait() le fils devient zombie ??? il devrait se terminer et point. Pire, la réponse est envoyée correctement comme avec le wait...
 
Pourquoi ?

oui, c'est normal.

Merci taz. Ca nous aide vachement O_o
 
Bon sérieux, si tu pouvais détailler une de tes réponses une fois Comment faire continuer le père sans créer de processus zombies ( donc sans wait() directement dans le père) ?

Ca doit avoir un lien avec SIGCHLD ça  

tu sais ce que c'est un zombie ?
t'es sur de pas vouloir faire des threads ?
ben quand un fils à fini, tu wait pour récupérer son statut, ça me parait normal. sinon, si tu ne wait pas pour récupérer son statut, ben par définition t'as un zombie : un processus terminé dont le père ignore la terminaison.

pourquoi pas un waitpid à la place de wait?

à faire dans le père de tous vos fils car -1 permet d'atteindre la fin de n'importe quel fils, alors que WHOHANG permet de ne pas bloquer (pas de fils mort/zombie? on continue le job).
Si waitpid est effectue dans un boucle while (par exemple) qui execute le fork, théoriquement, TOUS les fils qui passent en état zombie mourrons correctement
 
 
EDIT: hum... il peut avoir des zombies si votre process père est tué par un signal, pour eviter les zombies à la mort du père, il faut "installer" un handler des signaux)

 
Oui, car le probleme des threads, c'est que si on fait un exec() dedans, le process sera remplacé et donc notre serveur entier executera le CGI Enfin si c'est possible avec des threads ca nous simplifierai énormément la vie bien sur...
 
SIGCHLD est exactement ce que nous recherchions

mais c'est pas des thread bordel

 
Tu me dis :
 

 
Auquel je te réponds que faire un thread pour le execlp me semble un peu ... a moins que j'aieloupé quelque chose, nan

non, quand on te lis, c'est le bordel entre processus et thread. bon bref, faut que t'attrapes le dit signal et dans le gestionnaire, tu fous un wait .

 
ca cai en cours de faisage ( si on m'avait pas pris mon PC avec les sources à la fac, ce serait déjà fait )
 
Pour les process et les threads, non, c pas le bordel, au contraire :
-Un process principal et 10 threads
-le process principal récupère les requetes HTTP et les mets dans une liste chainée ( producteur/consommateurs )
-Les threads prennent un job sur la liste chainée et le traitent en renvoyant la réponse.
-Si le thread tombe sur un CGI, alors il fork(), son fils lance un exec et lui il lui envoie la requete brute via un pipe redirigé sur stdin , et apres avir envoyé la requete est sensé continuer son job sans attendre la fin du CGI  
 
voilà :

t'avais déjà demande conseil à ce propos ?

euh non, je pense pas, du moins, j'en ai pas le souvenir
 
Ah si, sur les semaphores !

je pige toujours pas l'intérêt de mettre du code derrière un execlp vu qu'il ne sera pas executé m'enfin...

ben ça n'en a aucun. le seul code qu'on mets derrière, c'est du code à exécuter au cas ou exec échoue

 
Maintenant il a sauté et se trouve dans le code du SIGCHLD ...