RHJPP (./3967) :
Mais que va-t-il maintenant se passer lorsque le processus principal va tout naturellement utiliser la mémoire qu'il a réservée ? La mémoire va être copiée, mais ce n'est pas du tout ce que je voulais ! Et les performances du serveur pendant la copie de ces 5 Go vont sans doute être réduites ! Bon, ce phénomène ne se produit souvent qu'à une petite échelle, mais il me semblerait plus correct de ne cloner que ce dont on a réellement besoin. fork fait trop de choses et il devrait être décomposé.

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é.

spectras (./3966) :
Du coup, dire que tu peux t'en passer et implémenter la copie toi-même… Tu peux évidemment faire sans, mais c'est alors à toi de développer cette fonctionnalité manuellement dans ton application, avec des outils qui ne sont pas appropriés : tu ne peux pas utiliser la MMU pour faire ça (sauf si tu décides de développer un driver pour ton appli, mais ça revient à faire un driver qui implémente fork() en fait).

Sans manipuler la MMU directement on la manipule forcément à travers les appels système. Tu peux a avoir une sémantique de copy-on-write au sein d'un processus, tu peux faire une sorte de cow-memcpy avec un shm que tu re-mmap en MAP_PRIVATE, pas besoin de patcher le kernel pour ça.


Ça faisait longtemps que j'étais pas passé sur yaronet, 5 ans ? c'est marrant de voir qu'il y a toujours les mêmes