J'allais faire cette même réponse. La programmation asynchrone n'ai pas neuve, nodejs la en partie remis au gout du jour mais cella existe depuis que la programmation existe.
Pour des besoins simples, je dirais meme que libuv est overkill, gère trop de possibilités et de techno/paradigme différent et qu'une simple "event loop" via un epoll avec une machine d'état derrière fonctionne dans la plus part des cas simples où la robustesse est préférable à la performance pure niveau I/O.
Aujourd'hui si on cherche les performances pures et qu'on a pas de contrainte de multi-platforme, je partirai plutôt directement sur IOuring https://github.com/axboe/liburing.
Y a d'ailleurs de temps en temps des discussions qui arrivent sur la "mailing list" kernel pour évoquer les fait de passer l'ensemble des syscalls via IOuring (double ring buffer entre userspace et kernelspace, un pour les demandes, l'autre pour les réponses).
[^] # Re: libuv
Posté par Tangi Colin . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 3 (+2/-0).
J'allais faire cette même réponse. La programmation asynchrone n'ai pas neuve, nodejs la en partie remis au gout du jour mais cella existe depuis que la programmation existe.
Pour des besoins simples, je dirais meme que libuv est overkill, gère trop de possibilités et de techno/paradigme différent et qu'une simple "event loop" via un epoll avec une machine d'état derrière fonctionne dans la plus part des cas simples où la robustesse est préférable à la performance pure niveau I/O.
Aujourd'hui si on cherche les performances pures et qu'on a pas de contrainte de multi-platforme, je partirai plutôt directement sur IOuring https://github.com/axboe/liburing.
Y a d'ailleurs de temps en temps des discussions qui arrivent sur la "mailing list" kernel pour évoquer les fait de passer l'ensemble des syscalls via IOuring (double ring buffer entre userspace et kernelspace, un pour les demandes, l'autre pour les réponses).