In generale, come funzionano i gestori di eventi?

Questo è un argomento generale, come funzionano i gestori di eventi?

Ciò significa dietro le quinte: cosa succede quando vengono create.

Ho un'idea approssimativa, ma vorrei averlo confermato.

event-programming implementations

— JHarley1
fonte

it.wikipedia.org/wiki/Observer_pattern

— Steven Evers

Fantastico, il modello Observer è stato quello che avevo scoperto: ho letto sul web riguardo a questo problema e ho letto un buon articolo sull'argomento Event Driven Programming. All'interno di questo documento discute il processo del modello di progettazione degli handlers. Per cui hai una serie di Eventi che arrivano a un Dispatcher che poi prende quell'evento e lo analizza per determinare il suo tipo di evento, quindi invia ogni evento a un gestore in grado di gestire eventi di quel tipo.

— JHarley1,

Spiega come il dispatcher sia un ciclo infinito che si arresta solo quando (ad esempio con un'applicazione GUI) il programma viene chiuso. E poi come hai un modello di osservatore (o il modello di pubblicazione / sottoscrizione) che è ampiamente usato per fare la programmazione guidata da eventi con framework GUI e come funziona sul principio di Hollywood di "Don't Call Us We Calls Call You" .

— JHarley1,

Diresti che la spiegazione sopra è adeguata?

— JHarley1,

Dipende. Per una panoramica di alto livello, va bene. Tuttavia, per una spiegazione esauriente e completa, diamine no. Naturalmente una spiegazione del genere sarebbe probabilmente molte pagine di lavoro in quanto questo può essere piuttosto elaborato in quanto potresti ad esempio entrare nelle cose degli eventi web vs desktop.

— JB King,

A un livello basso, i gestori di eventi funzionano spesso eseguendo il polling di un dispositivo e in attesa di un interrupt di processo. In sostanza, un thread in background si blocca, in attesa che si verifichi un interrupt di processo. Quando si verifica un interruzione, la funzione di polling interrompe il blocco. L'applicazione può quindi scoprire quale handle di dispositivo ha causato l'interrupt e che tipo di interrupt è stato e quindi agire di conseguenza (ad es. Invocando una funzione del gestore di eventi). Questo di solito viene fatto in un thread separato in modo che avvenga in modo asincrono.

Naturalmente, il modo in cui questo viene effettivamente implementato varia considerevolmente 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 le chiamate del sistema di selezione o polling . Uno o più descrittori di file / dispositivo (che sono associati a un dispositivo, come un socket di rete, una porta seriale / USB, ecc.) Vengono passati alla pollchiamata di sistema, che viene resa disponibile al programmatore tramite un'API C di basso livello. Quando si verifica un evento su uno di questi dispositivi (ad esempio, alcuni dati arrivano su una porta seriale), la chiamata del sistema di polling interrompe il blocco e l'applicazione può quindi determinare quale descrittore del dispositivo ha causato l'evento e che tipo di evento è stato .

Su Windows, questo viene gestito in modo diverso, ma i concetti sono sostanzialmente gli stessi.

— Charles Salvia
fonte