Re: [boost] [context review] Review starts today, Mars 21st 2011

Subject: Re: [boost] [context review] Review starts today, Mars 21st 2011
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-30 03:04:00

Hi Jeffrey,

> Oliver has put in the time for this library, along with Boost.Fiber and
> Boost.Coroutine.

boost.coroutine was written by Giovanni Piero Deretta!
I'm responsible for boost.fiber/boost.tasklet/boost.task - whic hare removed from the boost vault until boost.context isready.

 
> At this point, given that I'm not at all familiar with context technology
> and terminology, the "user-level" in "user-level context" seems
> superfluous.  I can only guess that there are "kernel-level" contexts...

yes - the kernel schedules kernel-level contexts

> *** How to build and install ***
> So, first you claim "Boost.Context provides an abstraction
> (boost::contexts::native_impl)...", then go on to say that
> "...boost::contexts::native_impl might not be available".

modification in the lib: fcontext_t will be used in favour of ucontext_t if available

> Yikes, I'm scared by all these build parameters.  Any way we can make
> building one implementation or the other easier?  Or maybe expand this
> section on how to build the fcontext implementation?

this is due a limitation of boost.build/bjam - Vladimir works on a new version of boost.build which provides architecture, instructionset, address-model as general properties instead of optional properties.

>  presume the middle column of the table
> are
> bjam invokations...? 

yes

> What if I don't use bjam to build stuff?

if you don't use the default boost build tool (==bjam) then you do compile it by yourself

> I'm a little uncomfortable with have two context implementations, where
> neither is actually available on all platforms. ...
> for Boost.Context to just choose the best implementation for each
> platform.

see my previous comment 

> It seems the only (documented) drawback with using asm_impl is failure to
> preserve signal masks and inability to be called by asynchronous signal
> handlers.  Are these sufficiently useful to preclude hiding which context
> implementation is used?  Any code that requires signal mask preservation
> and/or asynchronous signal handlers would have to conditionally use those
> anyway to remain cross-platform, right?

ucontext_t preserves signal masks so that the code in a ucontext_t can install it own signal mask.
boost.context requires that the code exyecuted by boost.context will not to change the signal mask.

> The parameters in the context::context( void (*)(void*), context const&,
> void*, stack_type&& ) seem out-of-order to me...especially separating the
> void* parameter from the function pointer parameter.  I suggest
> context::context( void (*)(void*), void*, context const& nxt, stack_type&&
> )

already changed

 
> Also, should this
> be boost::context<>::current() (at least as long as boost::context has
> template parameters)?  And why is boost::context::current() not listed
> among
> the other member functions of boost::context?

old stuff in the docu - the default context ctor represent the snashot of the current execution context.

> I would guess, but I'd have to think hard about it, that any program which
> uses boost::context must create at least two boost::context objects, and
> at
> least one of these objects must reference the current context.  Is this
> the
> case?

two context objects are required because you want to jump from one context to another (and maybe back)

> To switch back to the stalled context before the switched-to
> context's function returns, the stalled context must be passed (through
> the
> void* argument) to the switched-to context's function, right?

not sure what you are refering to - the void pointer in make_fcontext() is used to transport user data to the called fucntion

> Indeed, it's not clear *where* a protected_stack object allocates
> its memory from; at the very least *this* should be documented.
> - I don't know that I agree that a stack must protect against exceeding
> the
> stacksize (although protected_stack certainly must!)...surely there are
> situations where you *know* you have enough stack space for your
> particular
> application, and hence guard pages would be unnecessary.

the used stack should always! protected (==using a guard page at the end)!
Imagine you implement a recursive descent parser (recursive invokcation of a parsing function). it depends from the input how much recursive invocations (with local data) your parse as to call in order to parse your text. That means every call to the parsing function consumes stackspace.
If you reach the end of your stack two thins may happen if you do additional recursive calls to the parsing function. 

1.) you access memory not belonging to your process -> segmentation fault/access violation 

2.) or you overwrite your own memory which will result in unexpected/undefined behaviour of your app

Please note, a guard page doesn't allocate space from the physical memory (its a special entry in the page table).

>  It doesn't look
> like there's a way to determine the amount of free space / used space in a
> stack...is such a thing possible and/or useful?

boost::context::detail:.stack_helper provides three static functions

maximal_stacksize()
minimal_stacksize()
default_stacksize()

> - operator [unspecified-bool-type() and operator!() were confusing to me
> at
> first, as it left me wondering how a protected_stack object could be
> anything other than a stack!  I think, if default-constructible stacks
> (i.e., not-a-stack stacks) are deemed useful or necessary, they should be
> called something other than "not-a-stack", and more descriptively named
> member functions should be used to query the non-a-stack state.

move semantics of stack require to express a 'not-a-stack' which means the stack content was moved. please look in the docu of boost.thread where Anthony explains it better than me.

> For the assembler implementation of context switching, is it possible to
> explicitly calculate the number of cycles, via a summing of the cycle
> counts
> of the instructions? 

at least for x86 boost.context provides a tool counting the cycles for a switch (libs/context/performance)

regards,
Oliver
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de