Re: [boost] [context] Implementation comments

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
> 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