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 -
Am 22.03.2011 22:26, schrieb Vicente BOTET: 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