Puoi progettare il flusso di controllo in senso inverso per evitare più timer.
- Quando invii un'email, memorizza qualsiasi contesto necessario per una risposta. Per esempio. scrivi questo contesto in un database o file.
- Controlla regolarmente le risposte. Per esempio. potresti avere un singolo thread che controlla le email in arrivo. Ciò può comportare un timer o semplicemente attendere le notifiche push (ad esempio quando si utilizza push-IMAP).
- Una volta ricevuta una risposta, carica le informazioni necessarie (dal database) e invia l'email successiva.
Perché questa potrebbe essere una soluzione migliore?
- Siamo in grado di gestire molte più risposte in attesa perché non abbiamo bisogno di un thread per risposta in sospeso. Ciò consente di risparmiare memoria e tempo di CPU, al costo di una piccola quantità di spazio di archiviazione del database.
- Di conseguenza, anche in questo caso si tratta di una soluzione molto migliore se una risposta non viene mai.
- Se l'applicazione si blocca, può essere riavviata e continuerà con lo stato salvato.
Come osservazione generale, è spesso meglio avere eventi che innescano reazioni, invece di sondare o aspettare eventi. I concetti correlati vagamente includono Tell, non chiedere principio , promises , interfacce utente reattive (ad esempio JavaFX), server Web asincroni come NodeJS e l'idea di continuazioni : possiamo memorizzare il contesto di un thread e continuarlo in seguito. E naturalmente l'ampia classe di architetture basate sugli eventi in generale, in particolare idee come architettura di sourcing .