Oui, mais dans le cas d’une architecture i386 / x86_64 avec le MMU le changement de contexte processeur a un coût, peut entraîner une invalidation des caches alors que dans le modèle asynchrone il n’en est rien. Quand il faut gérer sur un serveur 1000 connexions simultanées cela prend tout son sens (j’ai testé).
L’article a été publié en 2003, il s’est passé des choses entre temps ! En particulier le modèle asynchrone tire parti du principe de localité et exploite au mieux les caches L1 et L2 dans le cas de processeurs multi-coeurs. Par ailleurs l’article fait référence à /dev/poll qui est en O(n) alors que l’on dispose maintenant de epoll_wait() qui est en O(1) , enfin d’autres choses m’ont bien fait rigoler dans cet article (les 100000 threads par exemple) mais je crains qu’il ne soit quelque peu obsolète.
Effectivement la programmation dite « asynchrone » est plantogène, en revanche si on se donne du mal on arrive à des résultats probants si on compare avec un équivalent worker thread. Mais tout dépend aussi du problème, je me place essentiellement dans le cas d’un serveur et non pas dans celui d’une application, par exemple, de simulation numérique où les contraintes sont totalement différentes.
Si ce n’est pas du développement système et s’il n’y a pas de contraintes particulière, autant laisser faire le système, sinon il est possible de lui donner un coup de pouce ; mais après ça commence à devenir une affaire de spécialiste...
Pour le 1 non. Le processeur travaille en adresses logiques pas physiques, le changement de contexte implique le rechargement de tables (LDT, TSS) et de descripteurs de segments ce qui qui peut avoir un coût véritablement très élevé si ces données ne sont pas dans le cache L1, contrairement au modèle « asynchrone ».
2. Même remarque.
3. Apache en mono thread (ça fait deux ans que je n’utilise plus Apache) ? S’il y a un lien ça m’intéresse histoire de comparer avec Nginx pour rigoler.