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

Subject: Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-24 03:06:28

> On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke <oliver.kowalke_at_[hidden]>
> 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