Re: [boost] [context review] Several Questions

Subject: Re: [boost] [context review] Several Questions
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-22 04:20:53

> > 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

It would be much more useful and I think this can be fully acceptable for 
users...

Other issue is that if somebody build boost with uncontext and links with shared
object and other builds boost with fcontext their interface is absolutly
similar but ABI is different.

So for example if Red Had provides Boost builded with fcontext and Debian with 
ucontext
then same executable would not be able to run even when linked to same library.

What may be ever worth when some binary library you use uses Xcontext and you 
compile with Ycontext
then it would fail badly especially if you both linked boost_context statically
then it would crash accidentially in different places.

I'm really concerned about ABI issues especially that non-default build is 
likely
one that is desired.

Artyom