Boost logo

Boost :

Subject: Re: [boost] [context] Why does boost::ctx::minimum_stacksize() on Windows return 65536
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2012-09-02 13:32:30


> > Why is the minimally possible stack size in Boost.Context on Windows
> > set to be 64k? This seems to be way too high for applications where
> > only a minimal amount of stack is required. I assume, that since
> > Boost.Context allocates the stack using VirtualAlloc the minimum
> > possible value should be equal to the page size (see
> >
> > 85).as
> > px).
> >
> boost.context provides a default implementation of a stack-allocator
> (class stack_allocator) which appends each stack a guard page (guard pages
> will not be mapped to physical pages - you don't was memory).
> Function VirtualProtect() is used to set the 'guard' flag on the page and
> requires VirtualAlloc().

I don't see how that info relates to my question, sorry. Even if I need only
4k of stack space (or 8k, or whatever), I still would like to get the guard
page detecting stack overruns.

> I decided to provide the same stacksize as Win32 Fiber API does - which is
> system's allocation granularity (64kB; using GetSystemInfo() ).

CreateFiberEx allows specifying committed and reserved stack sizes

> If context's default stack allocation does not satisfy your requirements
> you can easily implement and use your own stack allocator together with
> make_fcontext()/jump_fcontext().

I understand that I can implement my own allocator. But why should I be
forced to do so if all I need to change is to remove the check for the
minimal stack size. The constraint you're trying to enforce is something
belonging into the documentation, not the code. The current implementation
just makes your library less usable for people knowing what they're doing.

BTW, on an unrelated note: I think the ctx::minimum_stacksize() and
ctx::maximum_stacksize() functions should be tied to the allocator. They
should not be global as they will return wrong numbers if a custom allocator
is used. But that's just IMHO.

Regards Hartmut

Boost list run by bdawes at, gregod at, cpdaniel at, john at