devrait, je ne pense pas. "pourrait" sans doute. La motivation étant plutôt dans le style de programmation ou l'autodocumentation du code.
- W
Version imprimable
Je n'ai vu fonctionner cette fonction que sur un vieux VAX tout vermoulu....
Bon courage... surtout pour se substituer au compilateur :)Citation:
Le défaut d'API n'interdit pas de faire sa propre cuisine et de constuire sa pile à partir d'une liste de blocks mémoire alloué sur le tas.
-W
On parle bien ici de code "inline", donc alloué par un simple déplacement de pointeur dans la THREAD Stack... Si il sagit d'allouer dans une pile annexe, ca revient a faire un new avec une allocation spécifique.
Pour supporter cela l'architecture du VAX construit l'espace d'adressage d'un processus sur deux tables de pages. Ce qui permet de distribuer nos régions précédentes (code et données statiques, pile et tas) sur 2 zones mémoires dont la gestion est assistée par le matériel.
Sur les processeurs actuels nous avons en général 2 niveaux de page de tables rendant cette possibilité beaucoup plus générique.
Lorsqu'on développe des libraries de threads "lights", on passe du temps à switcher les registres d'un contexte à l'autre. La pile de chaque threadlet est allouée indépendamment l'une de l'autre dans le tas.Citation:
Bon courage... surtout pour se substituer au compilateur :)Citation:
Citation:
Le défaut d'API n'interdit pas de faire sa propre cuisine et de constuire sa pile à partir d'une liste de blocks mémoire alloué sur le tas.
-W
On parle bien ici de code "inline", donc alloué par un simple déplacement de pointeur dans la THREAD Stack... Si il sagit d'allouer dans une pile annexe, ca revient a faire un new avec une allocation spécifique.
Nous avons bien dans ce cas une "pile" - au sens contexte d'exécution - construite à partir de blocks mémoires alloués sur le tas et une mécanique pour passer de l'une à l'autre dont le compilateur n'a que faire.
- W