L'exemple que j'ai pris(PID differents) a pour consequence que:
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.
Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à -3.
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Quand a la doc de glibc, ben sur http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_toc.html(...) il n'y a rien du tout, tu l'a prise ou ou ta doc ?
Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.
Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.