Message du 22/03/11 22:44 De : "Oliver Kowalke" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [context review] Review - alternative version available
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).
Well, I believe that unix signals should be handled in a single place, but I'm not an expert in this domain. I would like to see a good rationale explaining the advantages of letting Boost.Context manage them. In any case the name asm_impl and native_impl are not adapted. I let you make some better suggestions than the current ones. Best, Vicente