Stack: maximale Größe?

rapso

sorry fuers hijacken des threads, aber wieso gibt es ueberhaupt ein limit? das OS kann dynamisch rausfinden wenn eine neue 'page' angefordert wird, es kann den stack am ende vom addressbereich anlegen und so koennte man in 4kb stuecken ohne viel zu verschwenden trotzdem jede groesse nutzen wolange der addresssbereich was frei hat.

ich verstehe das ja bei systemen mit nicht virtualisiertem speicher, aber windows?

volkard

rapso schrieb:

ich verstehe das ja bei systemen mit nicht virtualisiertem speicher, aber windows?

jo, technisch möglich wäre das, den heap und den stack aufeinanderzuwachsen zu lassen. wie bei DOS.
vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

volkard schrieb:

wie bei DOS. vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

Oder weil man inzwischen das Multithreading erfunden hat.

sothis_

ich denke eher das dies mit der größe des L2 und L3 (wenn vorhanden) caches des cpu's zu tun hat. denn solange der stack komplett darin platz findet, kann er einen erheblichen geschwindigkeitsvorteil bedeuten, daher wohl auch die eher moderaten defaults. es spricht allerdings nichts dagegen die stacksize unter linux mit ulimit auf meinetwegen 2GB hochzuschrauben, ich habs gerade mit einem kleinen rekursiven algorithmus getestet - funktioniert wunderbar, ich weiss aber nicht ob das noch andere implikationen zur folge hat.

volkard

vielfaden schrieb:

volkard schrieb:

wie bei DOS. vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

Oder weil man inzwischen das Multithreading erfunden hat.

deswegen das mit dem virtualisierten speicher. multithreading ist kein argument.

volkard schrieb:

deswegen das mit dem virtualisierten speicher. multithreading ist kein argument.

Dann mußt du auch schreiben, wo der (one and only) Stack ist bei mehreren Threads.

volkard

vielfaden schrieb:

Dann mußt du auch schreiben, wo der (one and only) Stack ist bei mehreren Threads.

der lebt allein in deinen gedanken, fürchte ich.

knivil

aber wieso gibt es ueberhaupt ein limit? das OS kann dynamisch rausfinden

Dynamisch bedeutet weniger performant, wo ist denn dann der Unterschied zum Heap. Wenn du das willst, dann nutze doch gleich den Heap.

volkard schrieb:

vielfaden schrieb:

volkard schrieb:

wie bei DOS. vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

Oder weil man inzwischen das Multithreading erfunden hat.

deswegen das mit dem virtualisierten speicher. multithreading ist kein argument.

doch. alle threads teilen sich den virtuellen adressraum eines prozesses. haste 10 mal grössere stacks, kannst du nur noch 1/10 der threads erzeugen.

zur ausgangsfrage: eigentlich viel zu allgemein. die allgemeine antwort wäre: der stack kann nur so gross sein, wie's die breite des stackpointers zulässt.

rapso

vielfaden schrieb:

volkard schrieb:

wie bei DOS. vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

Oder weil man inzwischen das Multithreading erfunden hat.

das ist allerdings ein guter punkt. die segmentregister zu nutzen waere vermutlich, gerade bei c++, keine loesung

rapso schrieb:

vielfaden schrieb:

volkard schrieb:

wie bei DOS. vielleicht machts man's einfach nicht, weil es nicht notwendig ist, und bei getrennten speicherbereichen manches dann noch einen tick einfacher ist.

Oder weil man inzwischen das Multithreading erfunden hat.

das ist allerdings ein guter punkt. die segmentregister zu nutzen waere vermutlich, gerade bei c++, keine loesung

c++ sind threads ja unbekannt, aber du könntest z.b. schlecht adressen von lokalen objekten an andere threads übergeben:

void f(void)
{
   int a;
   CreateThread (...., &a, ...);
   ....
}

^^wäre mit stacks, die sich nicht sehen, fast unmöglich.