OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of class stack_allocator. minimum_stacksize() returns pagesize + 1kB
Why + 1kb? Shouldn't the guard page have 4k as well?
maximum_stacksize() returns 1GB (but will never useable) default_stacksize() returns 64 kB is_stack_unbounded() will always return true for all Windows versions
stack_allocator creates a guard page at the lower end of the stack. maximum_stacksize() still has ! is_stack_unbounded() as preconditon - which means you will/can never use the value returned by maximum_stacksize() until I find some informations about those limit in the MSDN (for the several Windows flavours).
What do you think?
After some tests I got exceptions thrown by Windows because the stack was too small (8kB). The simple example 'jump.exe' didn't work. I've concerns that users of boost.context will complain that their apps do not work (because of a too small stack) and call boost.context garbage.
Yes, they will call it garbage. So just give them the megabytes they (think that they) need! It will be difficult to please all the people all the time. For example, I will be pleading for fine granularity of the stack size with sizes as small as 32 bytes. That's right, I really said 32 bytes! You want my opinion? Everyone will just assume that it works. And they will for the most part be using giant PCs and work stations. So just setup the default, naive stack with a few megabytes and allow for expert fine-tuned granularity down to small stack sizes with expert methods. Document these briefly. Sincerely, Chris.