Programmazione a eventi

Invece di aspettare che un'istruzione impartisca al programma il comando di elaborare una certa informazione, il sistema è predisposto per eseguire all'infinito un loop di istruzioni all'interno del quale vi sono istruzioni che verificano continuamente la comparsa delle informazioni da elaborare (potrebbe trattarsi della creazione di un file in una certa cartella o della pressione di un tasto del mouse o della tastiera), e quindi lanciare l'esecuzione della parte di programma scritta appositamente per gestire l'evento in questione. Programmare "a eventi" vuol dire, quindi, ridefinire in modo personalizzato le azioni "di default" con cui il sistema risponde al verificarsi di un certo evento.

Gli eventi esterni a cui il programma deve reagire possono essere rilevati mediante polling (interrogazione) eseguito all'interno di un loop di programma, oppure in risposta ad un Interrupt. In molte applicazioni si usa una combinazione di entrambe queste due tecniche.

I programmi che utilizzano la programmazione a eventi (denominati spesso "programmi event-driven") sono composti tipicamente da diversi brevi sotto-programmi, chiamati gestori degli eventi (event handlers), che sono eseguiti in risposta agli eventi esterni, e da un dispatcher, che effettua materialmente la chiamata, spesso utilizzando una coda degli eventi che contiene l'elenco degli eventi già verificatisi, ma non ancora "processati". In molti casi i gestori degli eventi possono, al loro interno, innescare ("trigger") altri eventi, producendo una cascata di eventi.

La programmazione a eventi incoraggia l'utilizzo di tecniche di programmazione flessibili ed asincrone, e si basa sul principio di imporre al programmatore meno vincoli possibile ("modeless"). I programmi dotati di interfaccia grafica sono tipicamente realizzati secondo l'approccio event-driven. I sistemi operativi sono un altro classico esempio di programmi event-driven su almeno due livelli. Al livello più basso i gestori di interrupt gestiscono gli eventi innescati dall'hardware, con il processore principale che agisce da dispatcher. Ad un livello superiore i sistemi operativi fungono da dispatcher per i processi attivi, passando dati ed, eventualmente, altri interrupt ad altri processi, che possono, a loro volta, gestire ad un livello più alto gli stessi eventi.

Un sistema, o programma, controllato da comandi può considerarsi un caso particolare di sistema o programma event-driven, in cui il sistema, normalmente inattivo, aspetta che si verifichi un evento molto particolare, cioè l'invio di un comando da parte dell'utente.

Questo esempio, scritto in pseudocodice, fornisce un esempio di lettura dati da un socket eseguita con tecnica event-driven:

function read_next_data(fd)
   data = read_async( fd )
   if len(data) = 0
       => Niente da leggere, registrati per la prossima lettura
       event_polling_register( fd, read_next_data )
       => Torna indietro per fare qualcos'altro
   else
       => Dati disponibili, ricevuta quantità dati pari a: len(data)
       add_data_to_buffer( buffer, data )
   endif

• Model–view–viewmodel
• Paradigma di programmazione