Discussion :

[deeal]

Bonjour,
je voulais avoir une petite explication sur les differentes piles utilises par la CLR

en effet j'ai compris un peu (j'espere)
la managed heap : c'est la ou sont alloues tout les objets references cree par gcnew ( la je n'ai pas de confusion)
j'ai plus confusion entre le stack et la CRT
est-ce que sur la CRT sont alloues tout les objet references crees par new? (seulement), et le stack il n'a que les object value

et est-ce la CLR alloue un espace managed heap pour chaque process?
ou c'est une espace commun a toutes les application utilisant la CLR?
et est-ce que c'est la meme chose pour les autres piles?

Merci

[M�dinoc]

La CRT n'est pas une zone m�moire, mais la biblioth�que standard (C Run-Time Library)
Et surtout, un tas (heap) est TOUT SAUF une pile (stack)

• Managed heap : C'est le tas manag�, o� se trouvent en effet tous les objets de type r�f�rence.
• CRT Heap : Tas non-manag� de la CRT : Objets cr��s par new (et en C, zones m�moires allou�es par malloc()).
• Stack : Pile, contient toutes les variables locales des fonctions : Types valeur et r�f�rences vers des objets de type r�f�rence.
  Il y a une pile par thread.
• Pour les variables static/shared, je ne sais pas o� elles sont mises en Manag�. Mais en non-manag�, c'est simplement dans la "zone de donn�es statiques".

Et pour information, il y a un process pour chaque programme .Net lanc�, donc les donn�es manag�es sont isol�es (enfin j'esp�re, car les partager en interne serait vraiment d�bile).

[deeal]

Et pour information, il y a un process pour chaque programme .Net lanc�, donc les donn�es manag�es sont isol�es (enfin j'esp�re, car les partager en interne serait vraiment d�bile).

Merci Medinoc.
juste pour le dernier point, je crois que avec .Net, on peut avoir un seul process pour plusieurs application, mais chaque application a son Application domain, non?

pas defaut oui , on a un process pour chaque application et donc un seul AppDomain
mais on peut demander au CLR de creer un seul process, et dedans creer plusieur APPDomain, et je voudrai bien voir comment est gerer la memoire comme cela

Merci

[M�dinoc]

D�sol�, je ne sais pas ce que sont les AppDomain. C'est un concept .Net ?

Au niveau process, je ne connais que Fiber ∈ Thread ∈ Process ∈ Job.

[deeal]

D�sol�, je ne sais pas ce que sont les AppDomain. C'est un concept .Net ?

Au niveau process, je ne connais que Fiber ∈ Thread ∈ Process ∈ Job.

oui c'est un concept du framework
deja il y'avait un probleme pour un singleton d'une classe, car c'est un singleton au sein d'une AppDomaine, et pas du processus

http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx
tu peux voir ce lien si tu veux
ou
http://msdn2.microsoft.com/en-us/library/dah4cwez.aspx
merci

[M�dinoc]

Ah oui, je viens de jeter un coup d'oeil.

Si j'ai bien compris, un process peut en effet contenir plusieurs applications, chacune dans son AppDomain, mais seulement si elles sont type-safe (ce qui selon moi signifie "En C# sans zones 'unsafe' ou en C++/CLI compil� avec /clr:safe", sachant que pour le VB je ne sais pas).
Cela doit vouloir dire qu'une application unsafe est toujours lanc�e dans un nouveau processus.

Mais apparemment, on ne peut pas cr�er deux applications dans le m�me AppDomain.

on peut demander au CLR de creer un seul process, et dedans creer plusieur APPDomain, et je voudrai bien voir comment est gerer la memoire comme cela

Si j'ai bien compris, la m�moire est partag�e (car ce n'est toujours qu'un seul process), mais le CLR s'assure qu'aucun AppDomain ne touche � la m�moire du voisin.

[deeal]

Si j'ai bien compris, la m�moire est partag�e (car ce n'est toujours qu'un seul process), mais le CLR s'assure qu'aucun AppDomain ne touche � la m�moire du voisin.

et donc la difference entre AppDomain est Thread, ce n'est pas de le partage memoire, car les thread aussi partagent la memoire
Merci Medinoc
je crois que j'ai bien compris la difference entre la CRT heap, managed et le stack