ovh > Je ne permets pas de telles accusations

Bon voila altar pour le coming out c'est fait ^^

Georgio et Altar sont dans un bateau...

Oups désolé philfr ^^ ( honte sur moi pour la confusion entre OS et distrib ^^ )

J'reponds pour Altar parce que j'connais un peu la machine pour laquelle il bosse

Oups oublié de noter :

2.6.14-2 et j'dirai qu'il a été recompilé à la sauce altar

(Et je réponds pour lui, car comme il est pas là il aura peut etre la surprise d'une jolie réponse lors de sa reconnexion )

Debian Sarge c'est pas un OS c'est une distribution GNU/Linux

Kernel 2.4 ou 2.6 ? Standard package Debian ou recompilé avec tes options ?

Puis d'abord, t'es pas Altar toi, pourquoi c'est toi qui réponds ?...

Debian Sarge

Quel OS ?

Ok, j'ai résolu le problème. Apparement, le scheduleur changeait de thread à la fin de chaque recv (ne me demander pas pourquoi) et certains recv étaient vraiment très court ce qui provoquait un swap entre les threads très fréquents ==> une utilisation cpu fort élevée.

philfr> Je lance le thread

Dis-nous aussi sur quelle version de quel OS et le cas échéant quelle version de libraire pthread.

N'oublie pas que en sortant de ton pthread_cond_wait, tu dois toujours checker si la condition est effectivement présente pour continuer, sinon tu dois repartir de suite dans ton wait.

Cela dit, les threads c'est mal ...
Hormis le vrai temps réel, ou la vraie concurrence cpu-intensive, la plupart des problèmes résolus aujourd'hui avec des threads peuvent en général être résolus par select() ou assimilé... Et c'est une tendance que j'observe de plus en plus dans les applications type serveur ou GUI. Je suis prêt à argumenter davantage dans un autre débat bien sûr...