./3891 ./3890> je pensais notamment aux cas de serveurs, où les besoins de changement d'identité / de permissions ont lieu après initiation de la connexion (voire après la négociation SSL, le cas échéant). Initialiser un nouveau processus et lui transférer la requète via IPC (puis récupérer la réponse afin de la transmettre au client) serait une contre-performance notoire.

Pour le pre-linking en mémoire, l'idée est d'avoir un processus qui charge un ensemble de libs, ce qui les linke. Il peut alors lancer des programmes qui utilisent ces libs très rapidement, il n'a qu'à forker et les libs sont déjà prêtes, avec toutes les références résolues. Ça présente aussi l'avantage de permettre de réduire la mémoire consommée par chaque processus, car les structures dynamiques communes sont partagées sur des pages en copy-on-write.
Je sais que kdeinit fait ça, il n'est sans doute pas le seul.

D'ailleurs, l'idée que la création d'un processus est une opération coûteuse est peut-être vraie sous windows (justement parce que ça passe par CreateProcess qui doit en créer un de toutes pièces), mais un fork() est presque aussi rapide qu'un pthread_create. Et quand le parallèlisme devient important, séparer les client par des fork() au lieu de créer des threads peut devenir plus efficace, à cause du surcoût de synchronisation pour l'accès au heap partagé.

Le choix de fork ou de pthread_create, en principe, n'est pas un choix de performance mais de fonctionnalité : veut-on isoler les espaces d'adressage ?