Subject: Re: [boost] [context review] Several Questions
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-22 04:54:27
>
> > > You can always fall-back to ucontext if assembly version is not
provided.
> > >
> > > I think it would be very useful. Because different parts of program
> > > may required different contexts and inability to use two of them
> > > in same executable is quite problematic.
> >
> > the problem is that it is unlikely that I can implement fcontext for all
> >platforms and
> > ucontext is not available for some platforms (for instance ARM - I know
> >glibc-ports
> > but you don't have always the possiblity to patch/recompile the C-lib).
> > that means on some systems boost::ucontext<>/boost::fcontext<> may
> > not be available. I've some doubt that this is acceptable.
> >
>
> The point is that my may provide something like that:
>
> boost::context<> // some default, fcontext if
>avalible
>
> otherwise ucontext
> boost::context<ucontext_with_fallback> // ucontext, unless available
>fallback
>
> to fcontext
> boost::context<fcontext_with_fallback> // fcontext, unless available
>fallback
>
> to ucontext
> boost::context<ucontext> // ucontext, fail to compile if not
> available
> boost::context<fcontext> // fcontext, fail to compile if not
> available
>
>
Or other option may be create:
a) boost::abstract_context and all ucontext, fcontext, fiber_context
that is to be implemented in terms of abstract context
So all changed would be binary compatible
b) make boost::context use pimpl ideom so all details are hidden behind
the scenes in the sources so switching Xcontext would not change
the ABI of the library.
Artyom