On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:

...

I've published an alternative version of boost.context - the user can decide in its code which implementation should be used.

I think I follow Vicentes suggestion - boost.context provides only one class (boost::context<>) which preferes fcontext(asm) implementation if available otherwise ucontext/fiber. I'll implement a test-app in order to check how this design influences UNIX signal handling (hopefully the impact will be only to require not to change the UNIX signal mask in context<>).

I certainly wouldn't ask you to try to implement these higher-level features in assembler. But I don't see why the library couldn't add C++ header files providing such features wrapped around the (assembler or native) underlying functionality.

It would require to do an additional allocation and it might be that the higher implementations can do it more efficient/better suitable for there purposes/not required by some higher libs. Otherwise those libs would pay for the additional memory allocaton even if it would not be required.

We will want features such as templatized callables and exception support in every higher-level library built on top of Context. Must every such library provide its own redundant, inconsistent implementation?

The higher libs can implement what they want and how they want.

Here are two different objects initialized in different ways, containing different state. Maybe they should be different classes?

I think they should not be different - both do the same (jumping to other context). The difference is only the one does and the other doesn't manage a stack - but bot represent an execution context.

Perhaps you're saying that the same wrapper machinery that handles a templated callable could provide an outermost try/catch(...). That wrapper, guaranteed not to throw a C++ exception, will be executed by the top-level function passed to Context.

Again, every realistic consumer of Context will need this...

I can add an additional trampoline function which has a try/catch-all block and issues an assertion if an exception was thrown. But this adds an additional indirection!

Okay, there's a default-constructed stack object which manages no memory, a stack object managing a memory area which is potentially useful for a processor stack, and a stack object managing a memory area actually in use by a processor stack. I'm still unclear on the usefulness of the first kind, a default-constructed stack object.

The first is required to be able to jump from any position in the code to the second kind of context (which starts a new execution context).

Sure! As I said, unless one selects the 10.4u (or earlier) SDK, the ucontext.h implementation should work. I haven't yet tried to build the Context library; is the ucontext.h implementation header-only?

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