+---------- On Feb 11, Jerry Asher said: > Are you really saying you cannot imagine how in a multithreaded > environment one can automatically and efficiently extend the stack?
Depends on what you mean by "extend the stack". A single-threaded program has a heap and a stack in a single address space. We put the heap at the bottom and the stack at the top and let them grow towards each other. Obviously this allows each the maximum room for growth; we don't have to put a fixed division point into the address space. If the stack grows down into a page that the heap wasn't already using, the OS can detect that and simply map physical memory to that part of the program's address space. This form of "extending the stack" is easy. Now, in a program with N threads, we have a heap and N stacks in a single address space. We must create N-1 divisions in the address space. (We could get away with floor((N-1)/2) divisions if we let half the stacks grow towards lower addresses and the other half grow towards higher addresses, but we'd still need O(N) divisions and the code would be messy.) The heap and one stack can share one part of the address space, but each of the other stacks needs its own part of the address space: Heap--> <--StackN ... <--Stack3 <--Stack2 <--StackN When thread 2 is created, only the address space at the top of stack 2 needs to be mapped to physical memory. As stack 2 grows, the memory allocation can be extended as in the single-threaded program. But once stack 2 exhausts its allocated address space, there's no where else to go. A C stack cannot be moved, so we can't slide stack 3 down to make more room. So the question is, how much address space should we allocate for each stack? I claim that any automatic method of choosing the allocation is going to fail for some class of programs. The programmer must ultimately take responsibility for choosing how much address space to allocate to each thread. In the case of AOLserver, the programmer may be the guy writing AOLserver, or it may be the guy writing the .tcl page that uses a lot of memory. One might argue that AOLserver's default allocation is wrong. But's a much different claim. OK, one more possibility occurs to me: you could allocate stack frames on the heap. This has an entirely different set of ramifications. If this is what you had in mind as a way to "automatically and efficiently extend the stack", great, but I'll be surprised if it's what you were using on the DEC-10 in 1979.
