This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A very silly question


On 2004-11-10 at 20:11:28 Daniel Kegel wrote:

>> I still need to try gcc 3.4.2 on a big C++ app I'm involved with at
>> work.  This is because gcc 3.4.0 ICE'd on it, hope it is fixed now...

> I had a couple C++ problems with 3.4.0 and 3.4.1, but each problem
> was fixed in the next release before I noticed it!

Sounds hopeful, will try as soon as I've got time. :)


>> So if you don't have swap, as is likely on such a device, you run out
>> of memory very quickly, if you want to have a multithreaded
>> application...

> Or just use ulimit -s to set the default thread stack size smaller,
> maybe?

The problem wasn't the maximum stack size, but the minimum/initial
size, which was bumped from 16 kB to 2 MB.  So even if you are very
careful in your thread handler(s) to not consume too much stack space,
you still eat up at least 2 MB per thread...  This seriously limits
the amount of threads you can run, obviously.

It's internal to glibc's pthread manager.  Before revision 1.54, they
used a #define INITIAL_STACK_SIZE of 16 k, and this was passed during
the actual mmap() request which allocates the thread stack.  By using
the MAP_GROWSDOWN flag to mmap(), the stack automatically grows as
needed.

From revision 1.55 and later, they decided to drop the MAP_GROWSDOWN,
probably due to portability issues (it's a Linuxism, I think, and not
all stacks grow downwards, naturally).  So they now always start with
a stack of 2 MB, or actually 2 MB minus a guard page.


>   People doing heavy multithreading need to care about that
> anyway, even on machines with virtual memory, since you run out
> of *address space* at only 500 threads with the default setting.

Well, in the case of our device, which has 32 MB, you run out of space
at about 16 threads, which is not an enormous amount...

(To make it worse, some people also forget to call pthread_join, so
thread resources don't really get freed, even after they've exited!
And then you run out of space really quickly.)

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]