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