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

Subject: Re: [boost] [context review] Review - alternative version available
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-22 17:41:48

Am 22.03.2011 22:26, schrieb Vicente BOTET:
> 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?
good question - because I'm currently focused on the boost.context 
review I didn't spend much time of the influences of the changed design -
probably as template argument.

> 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.

The problem is that the user can't choose between a boost::context<> 
version which can deal with UNIX signals (as ucontext functions do) or a 
fast assembler implementation (fcontext) if UNIX signals are out of 
scope/irrelevant /because handled in another place/thread - what ever).

>> 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.
OK - that is already done :^)

> 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.
>

if it is desired I'll do it - but how does it fit into boost (which is 
C++ centric/related)?

regards,
Oliver