Posté par JaguarWan .
En réponse au message Polling.
Évalué à 1.
Effectivement, ça mettra le même temps dans l'absolu (voire plus, avec l'overhead dû aux push()/pop() et aux context switches), mais en "fragmentant" le select() j'espère gagner en "répondant". En gros, au lieu d'attendre le résultat d'un gros select() pendant n secondes et de le dispatcher aux travailleurs, là les évènements devraient être distribués aux travailleurs en flux continu tout au long de ces n secondes.
Cependant, j'ai l'impression que ma démarche est un peu naïve, et j'aimerais avoir des avis sur une utilisation de select() qui soit "scalable". En interrogeant google, j'ai vu par exemple que le très performant serveur Zeus (closed source) utilise select() d'une manière optimisée. Mais vu que les sources ne sont pas disponibles, pas moyen de voir comment il procède...
Bien sûr, "ce qui entoure l'appel à select()" est également sur l'établi, mais j'ai particulièrement besoin de conseils pour l'écriture d'une méthode de polling portable...
[^] # Re: Pas clair
Posté par JaguarWan . En réponse au message Polling. Évalué à 1.
Cependant, j'ai l'impression que ma démarche est un peu naïve, et j'aimerais avoir des avis sur une utilisation de select() qui soit "scalable". En interrogeant google, j'ai vu par exemple que le très performant serveur Zeus (closed source) utilise select() d'une manière optimisée. Mais vu que les sources ne sont pas disponibles, pas moyen de voir comment il procède...
Bien sûr, "ce qui entoure l'appel à select()" est également sur l'établi, mais j'ai particulièrement besoin de conseils pour l'écriture d'une méthode de polling portable...