Re: [boost] [context review] Review - alternative version available

Subject: Re: [boost] [context review] Review - alternative version available
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-03-22 17:26:24

> Message du 22/03/11 21:50
> De : "Oliver Kowalke" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [context review] Review - alternative version available
> 
> Am 22.03.2011 21:20, schrieb Vicente BOTET:
> > Oliver, please it would be simpler if we review only one library. You 
> > could post here whatever you want, patches, explanations, but please 
> > don't request the reviewers to review another package.
> >
> ok
> 
> > Could you elaborate more on the asm_impl point, I think I've missed something? Please post here whatever do you want to change.
> >
> 
> Artyom has requested in its last postings that boost.context should 
> compile the implementations for fcontext (using assembler) as well 
> ucontext/Win Fiber (provided by the operating system) instead select 
> one at compile-time with bjam options.
> 
> The user can now decide which impl should be choosen by selecting the 
> corresponding class:
> 
> context< stack, asm_impl > : uses fcontext/assembler if available 
> (Windows is currently disabled)
> context< stack, native_impl > : uses ucontext from C-lib on UNIX (if 
> implemented) and Windows Fibers on Windows

I have a question with this design. Which will be the parameter used by Boost.Fiber, Boost.Taslet? Should them also provide this parameter?
I really think this is not a good option. The good solution for me will be that the library doesn't let the user choose the implementation for a given platform, so ABI problem are avoided If I remember the problem comes from the fact that the assembler used can not be compiled conditionally as not included in a C++ file. If you want to preserve this file structure you will need a build system that let you know what are the best implementation you can provide on a specific platform.

> I believe Artyom has right with his concerns about the ABI issues 
> (binary compatiblity) - I would probably prefer the alternative solution.
> Because I got little feedback in the last year I'd like to use this 
> review to get some comments for the alternative version.
> 
> I remember you already ask for such a solution some weeks ago.

Not exactly. What I was requesting is what you provide today with the context been non-copyable and non-movable.

Maybe you are thinking to the fact I requested you to make a uniform C interface for fcontext and implement it with ucontext or fibers when the asm implementation is not available. This is in line with the request of Arytom to provide a C-interface.

Best,
Vicente