Il ne parle pas de io_uring qui sera le futur (?) de la gestion des connexions en mode asynchrone avec par exemple une meilleure gestion du buffer de réception, si je me souviens bien car il n'est plus nécessaire de les pré-allouer en RAM.
Ce qui peut être problématique quand il y a beaucoup de connexions à gérer.
Il me semble qu'il n'y a pas de débat sur le fait qu'io_uring va remplacer epoll (comme epoll remplace des trucs comme select). Il y a beaucoup de travail dessus ces dernières années. Je ne connais pas l'API en elle même mais il me semble qu'il permet aussi de passer un ensemble d'évènement en un seul appel système (je peux être complètement à côté de la plaque).
La question de la sécurité finira par être réglée AMHA faut que ça mature.
Il m'est arrivé d'utiliser epoll et d'être un peu frustré par ses limitation (surtout le fait que certains événements kernel ne sont pas accessibles via des file descriptors), je suis alors allé voir le lien wikipedia d'io_uring, et j'ai l'impression qu'il a été implémenté pour réglé un problème de performances, et pas de fonctionnalités.
Ce qui m'intéresserait, ça serait de pouvoir gérer les signaux via epoll (ou io_uring) comme un fd normal.
Il y a eu, il fut un temps, le projet signalfd, mais je n'ai pas l'impression qu'il ait abouti.
Quelqu'un a des news sur ces sujets ?
HISTORIQUE
signalfd()
Linux 2.6.22, glibc 2.8.
signalfd4()
Linux 2.6.27.
Il y a aussi pidfd_open qui est plus récent (linux 5.3) qui permet de remplacer les wait par des select/poll/epoll.
À plus haut niveau, il peut être intéressant de regarder sd-event (la boucle d'évènement de systemd) qui permet de facilement mélanger une grande variété d'évènements (grâce justement à epoll et tous les trucfd).
# io_uring
Posté par woffer 🐧 . Évalué à 1.
Il ne parle pas de io_uring qui sera le futur (?) de la gestion des connexions en mode asynchrone avec par exemple une meilleure gestion du buffer de réception, si je me souviens bien car il n'est plus nécessaire de les pré-allouer en RAM.
Ce qui peut être problématique quand il y a beaucoup de connexions à gérer.
[^] # Re: io_uring
Posté par Glandos . Évalué à 4.
https://www.phoronix.com/news/Google-Restricting-IO_uring
Visiblement, io_uring, c'est super bien, mais ça pose trop de problèmes de sécurité à Google pour le moment.
[^] # Re: io_uring
Posté par barmic 🦦 . Évalué à 2.
Il me semble qu'il n'y a pas de débat sur le fait qu'io_uring va remplacer epoll (comme epoll remplace des trucs comme select). Il y a beaucoup de travail dessus ces dernières années. Je ne connais pas l'API en elle même mais il me semble qu'il permet aussi de passer un ensemble d'évènement en un seul appel système (je peux être complètement à côté de la plaque).
La question de la sécurité finira par être réglée AMHA faut que ça mature.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: io_uring
Posté par moi1392 . Évalué à 3.
Il m'est arrivé d'utiliser epoll et d'être un peu frustré par ses limitation (surtout le fait que certains événements kernel ne sont pas accessibles via des file descriptors), je suis alors allé voir le lien wikipedia d'io_uring, et j'ai l'impression qu'il a été implémenté pour réglé un problème de performances, et pas de fonctionnalités.
Ce qui m'intéresserait, ça serait de pouvoir gérer les signaux via epoll (ou io_uring) comme un fd normal.
Il y a eu, il fut un temps, le projet signalfd, mais je n'ai pas l'impression qu'il ait abouti.
Quelqu'un a des news sur ces sujets ?
[^] # Re: io_uring
Posté par Clément V . Évalué à 2.
man signalfdIl y a aussi
pidfd_openqui est plus récent (linux 5.3) qui permet de remplacer leswaitpar desselect/poll/epoll.À plus haut niveau, il peut être intéressant de regarder sd-event (la boucle d'évènement de systemd) qui permet de facilement mélanger une grande variété d'évènements (grâce justement à
epollet tous les trucfd).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.