J'essaie de comprendre ce qu'est une boucle d'événements. Souvent, l'explication est que dans une boucle d'événement, vous faites quelque chose jusqu'à ce que vous soyez averti qu'un événement s'est produit. Vous gérez ensuite l'événement et continuez à faire ce que vous faisiez auparavant.
Mapper la définition ci-dessus avec un exemple. J'ai un serveur qui "écoute" dans une boucle d'événement et quand une connexion de socket est détectée, les données de celle-ci sont lues et affichées, après quoi le serveur reprend / commence à écouter comme il le faisait auparavant.
Cependant, cet événement se produit et nous nous informons «comme ça» est trop difficile à gérer pour moi. Vous pouvez dire: "Ce n'est pas" juste comme ça ", vous devez enregistrer un auditeur d'événement". Mais qu'est-ce qu'un écouteur d'événement mais une fonction qui, pour une raison quelconque, ne revient pas? Est-il dans sa propre boucle, attendant d'être averti lorsqu'un événement se produit? L'auditeur d'événement doit-il également enregistrer un auditeur d'événement? Où finit-il?
Les événements sont une abstraction agréable à utiliser, bien qu’une abstraction. Je pense qu’en fin de compte, le scrutin est inévitable. Peut-être que nous ne le faisons pas dans notre code, mais les niveaux inférieurs (l’implémentation du langage de programmation ou le système d’exploitation) le font pour nous.
Cela revient essentiellement au pseudo-code suivant qui tourne assez bas pour ne pas attendre en attente:
while(True):
do stuff
check if event has happened (poll)
do other stuff
C’est ce que je comprends de l’idée et je voudrais savoir si c’est correct. Je suis ouvert à accepter que toute cette idée soit fondamentalement fausse, auquel cas j'aimerais une explication correcte.
EventSource
fait-on si on n’interroge pas l’entrée au clavier?