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 04:04:29

> > 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.
> >
> 
> That wasn't documented anywhere that I could see, so I presume this is a
> recent requirement?

yes

> Yes, I understand; this is why I used the phrase "there are situations
> where" rather than, e.g., "all situations are such that".
> 
> Please note, a guard page doesn't allocate space from the physical memory
> > (its a special entry in the page table).
> 
> 
> Yes, but requiring a guard page does limit where you can put your stack's
> memory.  E.g., should I be able to do
> 
>     char stack_space[256]; // okay, not properly aligned; use
> boost::type_with_alignment to get the right alignment
>     context c(..., stack_space);
> 
> as long as I *know* that the function which context c references will not
> use more than 256 bytes of stack space?  Let's just suppose that on all
> platforms I plan to support with the above code, 256 bytes is enough.  Is
> this just a bad idea?  If so, I think it warrants discussion in the
> documentation, and if not, I think the guard page requirement should be
> changed to a *recommendation*.

ok - you are still free to implement your own stack class - boost::context accepts any kind which follows the implicit interface (functions address() and size() )

> > maximal_stacksize()
> > minimal_stacksize()
> > default_stacksize()
> >
> 
> The fact that they are in a detail namespace renders them essentially
> invisible from a user's perspective.  So, again, are these functions
> useful?  Should they be exposed in the public interface?  Should they be
> requirements of the stack concept?

maybe I make those functions public

> > at least for x86 boost.context provides a tool counting the cycles for a
> > switch (libs/context/performance)
> >
> 
> I'm sorry to be picky, but I tend to think that the methodology one uses
> to generate performance statistics should be spelled out very
> explicitly.  I
> assume you used this tool to generate all the cycle counts in the table.
> I'm guessing it's not a static analysis tool (i.e., it doesn't actually
> run
> the code, which is what I was referring to in my comment), but rather a
> runtime analysis tool, judging by your performance notes, correct?

the tool runs the code (boost::context::jump_to()) and counts the CPU cycles

Oliver

-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl