• [^] # Re: Pas clair

    Posté par . En réponse au message Polling. Évalué à 2.

    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.

    Tu n'as pas bien compris comment fonctionne select : la fonction est bloquante *tant qu*''il n'y a pas d'évènements associés à tes sockets.
    Si on se place dans le cas de la lecture, le select rend la main dès q'une des sockets à des données à lire. Tu ne perds donc pas de temps à scruter les sockets une par une s'il n'y a rien à faire, l'OS s'en charge pour toi. Il n'y a donc aucune perte de temps à scruter des choses inutiles. Et crois moi, l'OS fais souvent les choses très bien, souvent mieux que toi (et que moi). Dans le cas des FD_SET et de ses petits frères, ce sont souvent des macros qui font des tests sur des masques de bits, et crois moi c'est bien plus rapide que de lier et de délier des objets dans des listes!

    Si on se cantonne à d'un programme mono-process, outre le fait que ce soit un bonheur à programmer par rapport à un programme multithread (pas de mutex à tout va), la difficulté dans ton cas concerne principalement la gestion de l'écriture, qui doit se faire en mode non bloquant. Là, pas de solution miracle: bien réfléchir !

    A ce propos, je pense que tu pourrais prendre des idées dans ce qui se fait dans le monde objet, et plus précisément en ce qui concerne les patterns 'proactor' et 'reactor'. Ces patterns sont dédiés au démultiplexage et à la distribution d'évènements