[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaTask 1.6.1
- From: Thomas Lauer <thomas.lauer@...>
- Date: Wed, 04 Jul 2007 13:23:32 +0100
Duck <firstname.lastname@example.org> wrote:
> > >Obviously, a small stack may produce other
> > >problems.
> > IIRC Windows will extend the stack of any thread
> >It is quite feasible to have 1500 threads with most of them
> >using no or almost no committed memory because they sleep.
> >But all these threads still need their share of reserved memory.
> Indeed...my point is just that IIRC, your concern that "a small stack may
> produce other problems" shouldn't be an issue _under Windows_ like it is
> under pthreads because thread stacks grow as needed.
> So if you start your 1500 threads with 256k each, you'll commit a lot less
> memory up front. If some of them need more stack they'll just get given it
> at run-time, unlike with pthreads, where the initial committed size is
> both the minimum and the maximum allocated to the thread.
Okay. To spell it out in full, what I meant is this: a process linked
with the default linker switches will get 1 MB stack reserve for the
main thread. That's enough for many, if not most, apps, so most people
don't even think about that.
However, a reserved stack size of 1 MB per thread (by default, threads
inherit the stack allocation of the main thread) means that the 2 GB
address space fills up after ~1700 threads are created. To squeeze in
more, one can lower the reserved stack space, let's say to 256 KB. This
allows about four times as many threads than a 1 MB reserve would but
each individual stack is now four times smaller. And ...
> Obviously, a small stack may produce other problems.
I hope I am making myself clear now.
web : http://thomaslauer.com/start