Douilles paresseuses - évolutivité?

Question

Demander plus en théorie, comment pourrais-je construire un serveur (ou application) qui utilise des sockets paresseux? J'envisage une application web qui déplace toutes ses données via des échanges JSON vers une servlet centrale de type API. Je pouvais laisser la connexion HTTP ouverte pour un peu après le transfert de toutes les données, écrire plus au client, comme une sorte de technologie push paresseux. Le navigateur peut également se reconnecter après un délai d'attente fermé le socket.

Interroger ce modèle, comment pourrais-je écrire l'application d'une manière qui ne consomme pas de mémoire camions chargés par ramification fil exponentielle? Chaque thread gérerait une ou plusieurs connexions? Comment chacun découvrirait-il de nouvelles données à transmettre? - je suppose que j'aurais besoin d'un dialogue entre les threads, plutôt que chaque thread recherche activement des données de son propre chef? Si je l'ai écrit un fil parent qui a donné naissance à x + 1 fils de discussion de l'enfant, chaque fil serait de 1: 1 ou plusieurs: 1 avec les clients? Pourrais-je rencontrer des problèmes de blocage? Quelle est l'empreinte mémoire de chaque gestionnaire de connexion supplémentaire?

Quelqu'un at-il des pensées à ce sujet? Je me demande à quoi cela ressemblerait en théorie plutôt qu'en pratique.

Answer 1

Vous pouvez ouvrir plusieurs sockets et utiliser select() ou poll() pour permettre au système d'exploitation de déterminer lequel d'entre eux nécessite un travail. De cette façon, vous n'avez besoin que d'un thread pour gérer un nombre arbitraire de sockets. Les lectures/écritures ne sont pas bloquées uniquement lorsque le système d'exploitation signale qu'il existe des données/un espace tampon disponible.

Answer 2

Je vous suggère de jeter un oeil à Twisted. Il utilise une approche légère avec un seul processus gérant les E/S asynchrones, puis plusieurs processus de travail. Comme les opérateurs peuvent bloquer les appels de fichiers et de bases de données, il est plus facile de les synchroniser dans les threads. La majeure partie des sockets ouverts peut ensuite être gérée par un thread parent unique utilisant l'E/S asynchrone.