$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [context] Why does boost::ctx::minimum_stacksize() on Windows return 65536
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2012-09-02 14:24:14
Am 02.09.2012 20:11, schrieb Hartmut Kaiser:
> Oliver,
>
>>> 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.
>> good point - both functions should be part of the stack_allocator
>> interface. I'll change it asap.
>>
>> What are the minimum and maximum stacksize on the several Windows versions
>> (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue.
>> Maybe pagesize? SUggestions?
> Well, I can't answer this question. All I know is that VirtualAlloc does not
> allow allocating less than a page, regardless of the (Windows) system. Thus
> I assume the minimal stack size in Boost.Context should be a page as well
> (well, plus guard page).
>
OK - following suggestion for Windows:
minimum_stacksize()/maximum_stacksize() will be static member funcs of
class stack_allocator.
minimum_stacksize() returns pagesize + 1kB
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?
Oliver