alliance-programmers '02
Re: vfork in mbk


Grégoire AVOT (gregoire.avot@lip6.fr)
Thu, 24 Jan 2002 10:55:37 +0100

Quelques infos : Sous Linux 2.x, le malloc (je reviens au fork plus tard) est particulier. La réservation mémoire n'est effective que lorsqu'elle est utilisée. C-a-d que si j'ai 100Mo de mémoire disponible sur ma machine, et que mon programme alloue 4 fois 50Mo par des malloc, ça marchera, aucun des malloc ne renvera NULL : c'est contraire à la sémantique de la fonction malloc, mais c'est comme ça, on fait avec. Curieusement, si je tente un malloc de 150Mo, là, ça me renvoie NULL. L'inconvéniant, c'est que lorsqu'on accède à plus de 100Mo, la programme termine violement par un SEGMENTATION FAULT. Pour nous qui faisons de la CAO, on peut considérer que Linux a un comportement qui n'est pas du tout adapté à nos besoins. Sous Solaris, le comportement du malloc est normal : lorsqu'à l'instant T la mémoire disponible n'est pas suffisante, le malloc renvoie NULL. C'est le concepteur qui décide ensuite ce qu'il veut faire. Je me demande si quelqu'un a testé ce comportement sous Windows. Concernant fork() et vfork(), je rappelle qu'ils n'ont pas du tout la même fonctionnalité, contrairement à ce que prétend le man de Irix : Le fork() : Les 2 processus s'exécutent en parallèle, chacun à sa mémoire. Le vfork() : Le processus pêre est bloqué jusqu'à ce que le fils se termine ( par un _exit(), et non pas exit(), c'est important) ou soit remplacé. La mémoire est partagée. Sous linux 2.0, vfork() est un alias de fork(). Sous linux 2.2, les deux fonctions ont bien leur caractéristiques respectives. Le rapport avec malloc(), et le choix du vfork()/fork() : Sous Linux, lorsque je fais un fork(), la mémoire n'est dupliquée que lorsque un des deux processus pere ou fils modifie la mémoire : c'est le mécanisme du "COPY ON WRITE", mais sans allocation préalable. On retombe alors dans les travers du malloc(), lorsque plus tard la mémoire viendrait à manquer (SEGMENTATION FAULT). Le fork devrait retourner -1 si il n'y a pas de ressources disponibles. Sous Linux, ça n'arrive jamais à cause de la façon dont est gérée la mémoire. Sous Solaris, le fork() regarde si la mémoire est disponible, et si ce n'est pas le cas, fork renvoie -1. Le vfork() a l'air standard dans les deux systèmes. En conclusion : Linux fait mal son boulot : il parie sur la disponibilité de la mémoire quand elle sera utilisée. Solaris ne fais pas ce parie, il assure qu'elle sera disponible. Pour Irix, faut voir, mais ça n'a pas de sens de dire qu'il ne s'agit que d'un problème de mémoire : il s'agit d'un problème de comportement lorsque les ressources ne sont plus disponibles. Le fork et le vfork on chacun leur role, et aucun ne remplace l'autre. En CAO, on travaille avec beaucoup de mémoire, c'est à dire plus que la moitié de la mémoire disponible. A l'époque, on avait utilisé naïvement le fork() suivit plus tard d'un execvp() dans le fils. Sous Linux, ça marchait toujours, mais sous Solaris, il arrivait que ça coince. C'est LA raison pour laquelle nous avions choisi vfork() par la suite : revision 1.14 date: 1999/10/28 12:09:06; author: karim; state: Exp; lines: +5 -5 remplace fork par vfork sinon pb avec solaris correction d'un core avec la variable MBK_FILE_TRACE quand extension est NULL. Je rejoins la suggestion de Fred : par défaut, il faut utiliser vfork(), sauf sur les systèmes qui ne l'on pas. Grégoire.

 



Alliance Web Site © 1997, 2002 ASIM/LIP6/UPMC, page maintained by Czo [Olivier Sirol] , last updated on 24 January 2002.