Posté par BFG .
En réponse au journal Gophrier 0.1.
Évalué à 1.
"lecture de fichiers asynchrone => fork/thread ?"
C'est tout l'inverse, les opérations d'E/S asynchrone visent à ne pas utiliser de fork/thread.
Les forks/threads sont nécessaires quand un appel de fonction risque de durer longtemps et donc d'empêcher de faire d'autres choses. Mais les E/S peuvent être utilisées de façon à ce qu'elles ne bloquent pas le reste.
Une opération d'E/S dite "synchrone" peut être lente, car l'appel à fread/fwrite (par exemple) ne se terminera qu'une fois les octets lus/écrits.
Je n'ai pas lu votre code, mais de ce que j'ai compris, vous avez utilisé select pour "lire" tous les sockets dans un seul endroit, plutôt que d'utiliser un thread par client (où chaque thread ferait de bêtes lectures bloquantes, même s'il ne se passe rien les 3/4 du temps).
select et consorts sont une idée de début pour faire des E/S "asynchrones" comparé à "un thread par client".
[^] # Re: Suggestions
Posté par BFG . En réponse au journal Gophrier 0.1. Évalué à 1.
C'est tout l'inverse, les opérations d'E/S asynchrone visent à ne pas utiliser de fork/thread.
Les forks/threads sont nécessaires quand un appel de fonction risque de durer longtemps et donc d'empêcher de faire d'autres choses. Mais les E/S peuvent être utilisées de façon à ce qu'elles ne bloquent pas le reste.
Une opération d'E/S dite "synchrone" peut être lente, car l'appel à fread/fwrite (par exemple) ne se terminera qu'une fois les octets lus/écrits.
Je n'ai pas lu votre code, mais de ce que j'ai compris, vous avez utilisé select pour "lire" tous les sockets dans un seul endroit, plutôt que d'utiliser un thread par client (où chaque thread ferait de bêtes lectures bloquantes, même s'il ne se passe rien les 3/4 du temps).
select et consorts sont une idée de début pour faire des E/S "asynchrones" comparé à "un thread par client".