Re: [PATCH] Use malloca instead alloca

[Rich Felker <dalias at aerifal dot cx>]

On Sun, Dec 30, 2012 at 12:48:50PM -0500, KOSAKI Motohiro wrote:
> >> For platform specific way best solution is to read where bottom of stack is
> >> and allocate only when at least say 32768 bytes are left.
> >> >
> > And when knowing stack boundaries I could also recognize stack pointer
> > by single comparison.
> >
> > It needs to define _STACK_TOP,_STACK_CUP, _STACK_SIZE macros for stack parameters.
> > I can find them by pthread_attr_getstack but this call is slow.
> 
> I think this approach has two issues.
> 
> 1) On LInux, RLIMIT_STACK doesn't affect to main thread. so there is
> no reliable stack limit detection way. Think mmap vs stack expansion
> race case for example.

I'm not sure this is correct, or perhaps I don't understand. The
entire virtual memory range covered by RLIMIT_STACK is reserved for
stack growth, but only the first 128k (this number seems to be
hard-coded in the kernel..?) is initially reserved in the
commit-charge sense.

> 2) setcontext/getcontext family provide to implement userland thread
> (it is sometimes called fiber or green thread). so
> pthread_attr_getstack is not suitable for getting generic  stack
> knowledge.

Also, signal handlers can be run on alternate stacks with sigaltstack,
and it's possible to call non-async-signal-safe functions in libc from
such signal handlers as long as you can ensure they did not interrupt
unsafe functions. A trivial way to do this is raise().

I agree it's wrong to try to measure the available stack space. Even
if it could be done reliably, you don't want to consume most of the
remaining stack space with alloca when the function is not a leaf
function, and other functions it calls still might need significant
stack space. It's really just bad policy for any function to use more
than a small, bounded amount of stack space.

Rich