En général, comment fonctionnent les gestionnaires d'événements?

Il s'agit d'un sujet général, comment fonctionnent les gestionnaires d'événements?

Cela signifie dans les coulisses - ce qui se passe quand ils sont créés.

J'ai une idée approximative - mais j'aimerais qu'elle soit confirmée.

event-programming implementations

— JHarley1
source

en.wikipedia.org/wiki/Observer_pattern

— Steven Evers

Brillant, le modèle Observer était ce que j'avais trouvé: j'ai lu sur le Web ce problème et j'ai lu un bon article sur le thème de la programmation pilotée par les événements. Dans cet article, il traite du processus du modèle de conception des gestionnaires. Par conséquent, vous avez une série d'événements qui arrivent à un répartiteur qui prend ensuite cet événement et l'analyser pour déterminer son type d'événement, puis envoyer chaque événement à un gestionnaire qui peut gérer les événements de ce type.

— JHarley1

Il explique comment le répartiteur est une boucle infinie qui ne s'arrête que lorsque (par exemple avec une application GUI) le programme est fermé. Et puis comment vous avez un modèle d'observateur (ou le modèle de publication / abonnement) qui est largement utilisé pour faire de la programmation événementielle avec des cadres d'interface graphique et comment cela fonctionne sur le principe hollywoodien de "Ne nous appelez pas, nous vous appellerons" .

— JHarley1

Diriez-vous que l'explication ci-dessus est adéquate?

— JHarley1

Ça dépend. Pour un aperçu de haut niveau, c'est bien. Cependant, pour une explication complète et approfondie, diable non. Bien sûr, une telle explication nécessiterait probablement de nombreuses pages de travail, car cela peut être assez sophistiqué, car vous pourriez par exemple accéder à des événements Web contre des événements de bureau.

— JB King

À un niveau inférieur, les gestionnaires d'événements fonctionnent souvent en interrogeant un périphérique et en attendant une interruption matérielle. Essentiellement, un thread d'arrière-plan se bloque, en attendant qu'une interruption matérielle se produise. Lorsqu'une interruption se produit, la fonction d'interrogation cesse de bloquer. L'application peut alors savoir quelle poignée de périphérique a provoqué l'interruption et de quel type d'interruption il s'agissait, puis agir en conséquence (par exemple en appelant une fonction de gestionnaire d'événements). Cela se fait généralement dans un thread séparé afin que cela se fasse de manière asynchrone.

Bien sûr, la façon dont cela est réellement mis en œuvre varie considérablement en fonction du système d'exploitation et du type d'appareil / d'entrée. Sur les systèmes UNIX, les gestionnaires d'événements sont implémentés pour des choses comme les sockets, les ports série ou USB via les appels système select ou poll . Un ou plusieurs descripteurs de fichier / périphérique (qui sont associés à un périphérique, comme une prise réseau, un port série / USB, etc.) sont transmis à l' pollappel système - qui est mis à la disposition du programmeur via une API C de bas niveau. Lorsqu'un événement se produit sur l'un de ces appareils (comme, par exemple, certaines données arrivent sur un port série), l'appel du système d'interrogation cesse de se bloquer et l'application peut alors déterminer quel descripteur d'appareil a provoqué l'événement et de quel type d'événement il s'agissait. .

Sous Windows, cela est géré différemment, mais les concepts sont fondamentalement les mêmes.

— Charles Salvia
source