In reply to : > These functions are expected to be used with sigaltstack and > coroutines. What is the added value of these functions, compared to what existing programs already do? I did a small survey of how a couple of single-threaded programs allocate their alternate stack: - The majority allocate it statically. - Some use malloc(). - Some use mmap(). - Some use alloca(), i.e. a portion of the already-allocated stack in the program's main() function. The size that these programs use are: - some use SIGSTKSZ, - some use 16 KiB, - some use 64 KiB. We know that 16 KiB is too small on some platforms, and that a static allocation of SIGSTKSZ bytes leads to a compilation error now. Therefore the implemented added value is: * The ability to use SIGSTKSZ without a compilation error. Other added value that would be useful in some cases are: * The ability to have a guard page at the stack top. This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE) is missing after the __mmap call. * The ability to have a guard page at the stack bottom. This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE) is missing after the __mmap call. * A verification that the allocated size is not larger than getrlimit(RLIMIT_STACK). If the system or the user has set a maximum stack size of, say, 8 MB, should the program be able to allocate a stack of 1 GB size, in this way? * Support for GCC nested functions, when they need an executable stack. GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to support this, even from dynamically loaded shared libraries. (See the attached test cases.) It is poor if this facility does not support it. * Automatic deallocation when the current thread exits. In those cases where a thread allocated a cstack_t for its own use, it is welcome if it can say "clean it up automatically when the thread exits". Otherwise some programmers will still prefer the "use alloca()" approach, which has this automatic cleanup property. Bruno