Subject: Re: [boost] [context] Implementation comments
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-01-19 03:58:46
> >>> 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
> > 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.
-- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk