ressources friendly

[thaeron]

Ayant constaté grâce à Djstey et [Leo_01] que le delay() présent dans NS faisait augmenter le switch context et les interruptions, et grâce à shagounet je pense qu'il faut implémenter différents niveaux d'attente.
On peut pas bloquer sur select (tant qu'aucune donnée n'est présente) si un timeout du bot est lancé. Or il y'a 2 types de timeouts : soit l'attente dépasse 1 et donc le temps dans delay() n'est pas critique (du moment il est inférieur à 1 seconde) soit le délai est de 0 ce qui correspondrait à une haute priorité.

Comme un timeout ne peut se s'ajouter tout seul, on a 3 niveaux :
pas de timeout : on peut bloquer sur select(),
timeouts normaux : on peut augmenter le delay(),
timeouts critiques : on passe à un delay() assez court.

Le plus difficile va être de comptabiliser correctement chaque timeout en prenant en compte les unload du module par le user ou par les protections.

[thaeron]

je propose les trois états NS_NO_LATENCY, NS_LOW_LATENCY, NS_CAN_WAIT

[thaeron]

Après une nouvelle discussion avec Djstey une autre solution plus audacieuse est possible. L'idée est de créer 2 nouvelles fonctions par exemple "reg_my_fd" et "unreg_my_fd" qui permettraient aux modules laisser le select du kernel se charger de savoir si des données sont en attente ou pas. Ainsi on aurait plus besoin dans les modules d'avoir des timeouts de 0s (ce qui est utilisé que les fds dans l'état actuel des choses). Et donc on pourrait mettre un GROS timeout sur select (par exemple 500ms).

[thaeron]

Le code vient d'être commité. Voir changeset [392]. C'est un gros morceau. Il est en principe finalisé et fonctionnel. Le composant requete a été adapté cependant il lui manque encore la gestion des timeouts des connexions. Il faudrait encore adapter le module pasting et mod_update.
Il met aussi en évidence le problème de redondance du code au niveau des protections lors des appels pour les handlers normaux/timeouts/hook/fd qu'il faudrait mutualiser.