----- Original Message -----
From: "Matthieu Herrb" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 08, 2003 3:52 AM
Subject: Re: stack size


> mnicolet wrote (in a message from Tuesday 8)
>  > May be this question is not strictly suited to this list, but I see
lots of
>  > people contributing from lots of different platforms.
>  > The question regards to stack space management under different
platforms, or
>  > execution models.
>
> On Unix-like systems (and I guess in modern MS Window too) the virtual
> memory system allows to allocate a large stack for each process. Real
> memory is used only as stack grows and as virtual addresses need to
> have real memory pages vired to them.
>
> There still is a physical fixed stack size limit, but it's generally
> set quite high.
>
> I don't know any system without shared memory that would behave this
> way. In VxWorks you specify the stack size at task creation and it's
> allocating memory from the global pool.
>
I forget to mention: QNX does use virtual memory, ( reliyng on the processor
for actual memory management ) but no disk paging.
So it behaves like VxWorks, i.e, early and _true_ stack allocation.
>
> Matthieu

Thank you.
You answered me what I was expecting: no system allows for a true or full
dynamic stack size.
Another wording: on every system one could reach some stack limit, and
therefore one migth care about this figure.
So, my true question comes into scene.
The people who ported XFree86 to QNX 4.x setted the stack size hint to the
Watcom linker to 4 Mb ( yes, 4 Mb ) for the server.
I am wondering why a so high figure. I tried to grep the sources searching
for some form of alloca usage ( the native one or a home brew, Postgresql
style ) without success. In fact, all what is malloc and free related is
coded using macros, which even appear redefined for some modules.
But what I cannot figure simply is the possible recursions, and/or giant
local objects.
Is there a true need for such stack size ?
marcelo

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to