Le cas des fork

Nous pensons qu'il est envisageable de réaliser, tout comme nous l'avons fait avec les threads, un "logiciel" de génération de L-systèmes, dont l'évolution parallèle serait exécutée par un ensemble de fork(). Cependant, nous avons quelques questions et quelques remarques à faire.

Premièrement, un partage de ressources est absolument nécessaire. Aussi bien au niveau des contraintes physiques (ombre, gène...) que temporelle (saisons). On pourrait néanmoins s'en passer en ajoutant des communications inter-processus par des tubes (cf. [UNIX]), mais cela augmente considérablement la complexité du logiciel.

Sous Unix, tout processus doit être lancé par l'appel système fork. Or, la création de processus ayant une partie de mémoire partagée est simplifiée par l'appel de la fonction clone(). Cette fonction réalise d'une part un fork(), et d'autre part, un partage de données entre le processus ainsi créé et le processus père.

Cependant, la gestion de l'ordonnancement des processus serait alors cantonnée à l'appel de la fonction nice(). Il n'y aura donc pas plus de contrôle qu'avec les threads (cf. partie 4.2).

Enfin, l'idée d'affecter un processus à chaque branche est à bannir car le nombre de branches d'un arbre croît exponentiellement. Par contre, on pourrait imaginer une branche dite "importante", devenir un processus. On aurait alors un mixe threads-processus. Mais nous pensons que ce mélange serait finalement plus complexe à gérer qu'il n'apporterait d'améliorations (cf. partie 4.2).