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.
The UNIX signals are not handled/managed by boost.context. In the case of ucontext (native_impl) the thread which runs boost.context can unblock and handle UNIX signals. For instance a platform which doesn't support kernel threads but has UNIX signal handling must handle signals in the same thread. In the other case (fcontext == asm_impl) the thread must block all UNIX signals.
In any case the name asm_impl and native_impl are not adapted. I let you > make some better suggestions than the current ones.
Well you know finding decriptive names for classes is not so easy (at least for me) - do you have a suggestion? regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de