b'\n_START_ARTICLE_\nProgrammazione a eventi\n_START_SECTION_\nGeneralit\xc3\xa0\n_START_PARAGRAPH_\nInvece di aspettare che un\'istruzione impartisca al programma il comando di elaborare una certa informazione, il sistema \xc3\xa8 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._NEWLINE_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._NEWLINE_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\xc3\xa0 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.\n_START_SECTION_\nAmbiti di applicazione\n_START_PARAGRAPH_\nLa 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\xc3\xb9 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\xc3\xb9 alto gli stessi eventi._NEWLINE_Un sistema, o programma, controllato da comandi pu\xc3\xb2 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\xc3\xa8 l\'invio di un comando da parte dell\'utente.\n_START_SECTION_\nEsempio\n_START_PARAGRAPH_\nQuesto esempio, scritto in pseudocodice, fornisce un esempio di lettura dati da un socket eseguita con tecnica event-driven:_NEWLINE_function read_next_data(fd)_NEWLINE_   data = read_async( fd )_NEWLINE_   if len(data) = 0_NEWLINE_       => Niente da leggere, registrati per la prossima lettura_NEWLINE_       event_polling_register( fd, read_next_data )_NEWLINE_       => Torna indietro per fare qualcos\'altro_NEWLINE_   else_NEWLINE_       => Dati disponibili, ricevuta quantit\xc3\xa0 dati pari a: len(data)_NEWLINE_       add_data_to_buffer( buffer, data )_NEWLINE_   endif'