Questo è un argomento generale, Come funzionano i gestori di eventi?
Ciò significa dietro le quinte - cosa succede quando vengono creati.
Ho un'idea approssimativa, ma vorrei confermarla.
Su un livello basso, i gestori di eventi spesso lavorano con il polling di un dispositivo e in attesa di un interrupt hardware. In sostanza, un thread in background si blocca, in attesa che si verifichi un interrupt hardware. Quando si verifica un'interruzione, la funzione di polling smette di bloccare. L'applicazione può quindi scoprire quale maniglia del dispositivo ha causato l'interruzione e quale tipo di interruzione era, e quindi agire di conseguenza (ad esempio invocando una funzione di gestore di eventi). Questo di solito è fatto in un thread separato in modo che avvenga in modo asincrono.
Naturalmente, il modo in cui questo viene effettivamente implementato varia notevolmente a seconda del sistema operativo e del tipo di dispositivo / input. Sui sistemi UNIX, un modo in cui i gestori di eventi sono implementati per cose come socket, porte seriali o USB è attraverso select o sondaggio chiamate di sistema. Uno o più file / descrittori di dispositivo (che sono associati a un dispositivo, come una presa di rete, una porta seriale / USB, ecc.) Vengono passati alla chiamata di sistema poll - che viene resa disponibile al programmatore tramite un'API C di basso livello. Quando si verifica un evento su uno di questi dispositivi, (come dire, alcuni dati arrivano su una porta seriale), la chiamata del sistema di polling smette di bloccare e l'applicazione può quindi determinare quale descrittore di dispositivo ha causato l'evento e quale tipo di evento è stato .
Su Windows questo è gestito in modo diverso, ma i concetti sono fondamentalmente gli stessi.
Leggi altre domande sui tag implementations event-programming