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] |
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] |