This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
David Mosberger <davidm@hpl.hp.com> writes: > >> that is one solution. All the other CPUs who want thread_top need > >> to use thread_bottom + stack_size to get thread_top in their > >> clone.S. > > Uli> This only makes sense if the kernel is actually able to limit > Uli> the growth of the stack without the user creating an artificial > Uli> barrier (as we do in the moment). > > Why do you think so? If you have a stack which grows downwards and the you feed the low stack address and the size, the kernel will have to compute the high address for itself. Then the user can assume that this address range is taken. But it's not. The kernel can place arbitrary mmap()ed blocks just in the middle and then? This problem of course exists with the current implementation as well but at least the interface does not suggest something differently. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |