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