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 18:37:19

> Message du 22/03/11 22:44
> De : "Oliver Kowalke" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [context review] Review - alternative version available
> 
> 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).

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