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