On Thu, Sep 14, 2000, Matt Sherer wrote:
> This is weird - I'm not a pth guru (by any means), but I've used it a
> fair amount, and am pretty familiar with it. A strange error has me
> confused - right now, I've got a bunch of really cpu-intensive,
> stack-heavy threads. They work fine. I added another one in, probably
> the simplest of all, that basically opens a file, and does a pth_select
> call on it. The select wakes up, but if i try to read from the file
> descriptor, I get a stack overflow on that thread. Raising it's stack
> size to 128000 solves it, but I'm wondering why a simple select/read
> call can overflow the stack while the other threads are dozens of levels
> deep, with a lot more stack-based data structures. Its more of a
> curiosity than anything - there's no global stack parameters or anything
> that would come into play by adding another thread, would there?
> (Actually, I shut down several of the others, and the problem is
> consistent, so it's probably not a matter of adding 1 to n and crossing
> some threshold.)
Yes, adding or removing some other threads in no way affect a stacks
stack.
There are only one good reason I can think of which cause the stack
overflow in such a "simple thread": Some of your functions or functions
inside some other libraries (libc, etc.) use large variables on the
stack. In C, every variable not declared "static" in a function is per
default allocated from the run-time stack. So, if you have a simple
"char buf[SIZE]" somewhere and SIZE is a few KB in size, this noticably
fills the stack of the thread while the function's scope is active.
Check your thread for such things.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
