Pour des opérations normales, ça passerais. Par contre, si tu veux lancer des milliers de services (genre, des VPS comme le faisait Pantheon, un des sponsors de systemd à l'époque), ça peut rajouter de la charge inutilement (ne serait que pour faire une boucle sur tout les FD avec select par exemple, même si je suppose que le kernel a peut être des optims à ce niveau).
Certes.
Petit détail ceci dit: select(2) est obsolète, il vaut mieux utiliser poll(2) pour du portable, et pour du non portable, faut voir avec l'OS.
Notamment:
WARNING: select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024)—an unreasonably low limit for many modern applications—and this limitation will not change. All modern applications should instead use poll(2) or epoll(7), which do not suffer this limitation.
Accessoirement, le truc vraiment bien avec poll(2) c'est qu'il n'y a pas besoin de recréer le tableau a chaque itération, c'est bien pratique. Et puis, pas besoin de macros pour s'en servir, l'interface juste "coule de source".
C'était le moment culturel :)
Dans le cas de systemd, compte tenu de leurs positions, j'ose espérer qu'ils utilisent epoll(2) et non select/poll, justement, parce qu'en terme de perfs c'est mieux, qu'ils disent.
En vrai, je ne suis pas sûr qu'une boucle sur quelques milliers de pollfd soit lente, d'autant plus que si c'set bien fait, il sera rarement utile d'itérer sur la totalité, sauf en cas de gros traffic ou si ceux qui ont un événement sont à la fin. Ok, ça fait un très, très gros "sauf".
Je pense qu'en effet sur un cas de serveur avec plusieurs milliers de daemons/services, systemd sera l'un des meilleurs en terme de performance, ne serait-ce que parce que pas besoin d'allouer 4Kio de RAM pour chaque process comme le ferait par exemple runit (dans le cas d'un linkage statique, hein, ou avec muslC. Parce que link dynamique avec glibc6, c'est direct 750Kio de bouffés par process, non je ne sais pas pourquoi).
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 2.
Certes.
Petit détail ceci dit:
select(2)est obsolète, il vaut mieux utiliserpoll(2)pour du portable, et pour du non portable, faut voir avec l'OS.Notamment:
Accessoirement, le truc vraiment bien avec
poll(2)c'est qu'il n'y a pas besoin de recréer le tableau a chaque itération, c'est bien pratique. Et puis, pas besoin de macros pour s'en servir, l'interface juste "coule de source".C'était le moment culturel :)
Dans le cas de systemd, compte tenu de leurs positions, j'ose espérer qu'ils utilisent
epoll(2)et non select/poll, justement, parce qu'en terme de perfs c'est mieux, qu'ils disent.En vrai, je ne suis pas sûr qu'une boucle sur quelques milliers de pollfd soit lente, d'autant plus que si c'set bien fait, il sera rarement utile d'itérer sur la totalité, sauf en cas de gros traffic ou si ceux qui ont un événement sont à la fin. Ok, ça fait un très, très gros "sauf".
Je pense qu'en effet sur un cas de serveur avec plusieurs milliers de daemons/services, systemd sera l'un des meilleurs en terme de performance, ne serait-ce que parce que pas besoin d'allouer 4Kio de RAM pour chaque process comme le ferait par exemple runit (dans le cas d'un linkage statique, hein, ou avec muslC. Parce que link dynamique avec glibc6, c'est direct 750Kio de bouffés par process, non je ne sais pas pourquoi).