C’est par exemple le cas d’un listener sur un port réseau, qui délèguerait à un thread chaque nouvelle connexion
C'est exactement pour ce cas là que l'asynchrone marche. Et justement, il ne faut pas faire de thread. Et il faut gérer les exceptions, pour éviter qu'un client ne pollue le programme complet.
Bon après, il y a d'autres cas où oui, l'asynchrone ne marche pas bien, notamment quand les tâches sont complexes en calculs, et ne sont pas limitées par les entrées/sorties. Par exemple, décoder 16 flux vidéos de caméras en parallèle. Là, il faut clairement des threads, avec vaguement de temps en temps de la synchronisation.
[^] # Re: Rx
Posté par Glandos . En réponse au journal La programmation concurrente en mode Goto. Évalué à 3.
C'est exactement pour ce cas là que l'asynchrone marche. Et justement, il ne faut pas faire de thread. Et il faut gérer les exceptions, pour éviter qu'un client ne pollue le programme complet.
Voir http://www.kegel.com/c10k.html
Bon après, il y a d'autres cas où oui, l'asynchrone ne marche pas bien, notamment quand les tâches sont complexes en calculs, et ne sont pas limitées par les entrées/sorties. Par exemple, décoder 16 flux vidéos de caméras en parallèle. Là, il faut clairement des threads, avec vaguement de temps en temps de la synchronisation.