This is the mail archive of the mailing list for the glibc project.

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: Fixed size of thread stacks in the nptl pthread implementation

On Mon, Feb 06, 2012 at 01:33:59AM -0500, Carlos O'Donell wrote:
> The default is to use a 1-byte guard which always rounds up to a
> 1-page guard. Currently glibc does not support dynamically growing
> thread stacks. The guard would prevent the thread from easily using
> any memory beyond the originally allocated amount. As the application
> stack usage grows the thread will eventually try to use the guard
> page(s) and fail, therefore the stack won't grow even if supported by
> the kernel.

Thanks, that's what I thought. So I think the patch should be safe for

> Yes, I believe that support for a default where the stack grows might be useful.
> If you call munmap on a region that was grown by the kernel will it
> free the entire memory region including the additional pages?

This will be a problem with thread stacks. Based on how munmap seems
to be implemented right now, it will only unmap the length that was
mapped in and the grown region will likely be wasted. This also seems
to be the case with mappings that are mapped in with MAP_GROWSDOWN.
I'm trying to come up with a test to verify this.


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