twindruff (./3975) :
C'est là que tu te trompes, le copy-on-write s'effectue à une granularité de page, souvent 4ko pour résumer. Donc si l'état mémoire des deux processus dérive, ce sera par petits pas de 4ko, l'espace mémoire complet n'est pas dupliqué. Et c'est donc exactement l'effet recherché.

Pas du tout. L'effet recherché n'est pas du tout de dupliquer tout l'espace mémoire modifié par le processus parent. Oui, la copie ne se fait que page par page, mais ça change quoi ? Dans mon exemple, les 5 Go alloués ne l'ont pas été pour faire joli, ils sont utilisés... Alors oui, si le processus parent ne fait rien pendant que son enfant travaille, c'est cool, pas de problème. Mais s'il touche à de la mémoire, celle-ci est recopiée et si c'est une partie que le fils n'utilise pas, elle l'est quand même, pour rien. Si un processus lourd est lancé en parallèle, c'est bien parce que la tâche à accomplir risque de prendre du temps alors que le processus parent a autre chose à faire. Et souvent, faire quelque chose implique de modifier de la mémoire. Alors ok, s'il modifie peu de choses, fork fait à peu près ce qu'on veut, mais sinon, non.

Je ne comprends pas cette volonté de prouver que quelque chose est parfait alors que ce n'est pas le cas. fork a ses avantages comme la simplicité dans certains cas, mais a des défauts dans d'autres. En fait, ce ne sont pas vraiment des défauts, c'est qu'il n'est pas adapté. fork ne devrait pas être systématiquement utilisé lorsque l'on souhaite lancer un processus lourd utilisant la copie d'une zone mémoire du parent. On devrait pouvoir demander une copie (qui ne sera effectuée que lors de la modification) d'une zone mémoire et la donner en paramètre à un nouveau processus. C'est certainement possible, mais pas simplement avec fork.