Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
some ABIs require some hidden space at the begin of the stack and especially alignment
Can malloc be used to get this hiden space?
mallolc() does add some managment stuff into the allocated memory chunk - and this what you realy don't want on your stack.
In any case I find the use of mmap a bad choice when no protection is required.
why? mmap() is a good choice if you require aligned memory even if you do not use guard pages.
Can malloc be used to get aligned memory?
malloc() uses internally mmap(). it saves only some additional data on the allocated memory chunk.
I don't understand your note - the lib does provide an abstraction over ucontext, fcontext, fibers etc.
Note that I didn't talk of fibers :) As for me fibers are a higer level abstraction. Of course Fibers can be used as a detail implementation of the Context concept, but his interface shouldn't be considered when defining the one for Context.
I refered to ucontext_t, fcontext_t and Windows Fibers - sorry to be unspecific in this point. Some additional points to your request for separating stack allocation from context creation: Windows Fiber API (which is used as an implementation detail on Windows) doesn't allow to pass an self-allocated stack to CreateFiber(). So this would break the interface of boost::context. Regards, Oliver -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl