boost.context-1.61版本的设计模型变化

前言

之前写了个C++的协程框架libcopp，底层使用的是boost.context实现，然后剥离了对boost的依赖。然而这样意味着我必须时常跟进boost.context的更新。

顺带提一下这个协程库已经在我们线上服务器版本中使用了。

从最初的boost版本（我忘了从哪个版本开始了）一直到1.60版本，boost.context的变化都不大，都只是补全一些新的架构和体系结构，还有就是修复一些小细节的BUG，再就是增加了对valgrind的支持（之前写过一个Merge记录提到过）。新增的功能也只有execution_context(现在叫execution_context_v1)，这个东西我的libcopp里其实包含了这个功能，并且本身做得比它要功能丰富，所以没有接入的必要。另外在1.60版本的时候尝试使用Windows里的fiber（当然默认是关闭的），在1.61版本里被移除了。这些细节都不是特别重要，主要还是1.61版本的变化。

然而这次变化就比较大了，首先所有的API都变更了，汇编代码里的参数和返回值也都发生了变化，当然语义也不一样了，另外还增加了新的APIontop_fcontext。这些变化使得libcopp的逻辑关系也必须有一些相应的调整，为了理清思路，这些都在后面分析。

设计模型变化

API变化

先来看看原先的底层API

namespace boost {
namespace context {

/**
 * @biref 执行环境上下文
 */
typedef void*   fcontext_t;

/**
 * @biref 跳转到目标上下文
 * @param ofc 当前的上下文会保存到ofc中
 * @param nfc 跳转到的目标上下文
 * @param vp 如果是第一次跳转，作为函数参数传入，如果是调回到jump_fcontext，这个是返回值
 * @param preserve_fpu 是否复制FPU（浮点数寄存器）数据
 * @return 如果调回时的透传参数
 */
extern "C" BOOST_CONTEXT_DECL
intptr_t BOOST_CONTEXT_CALLDECL jump_fcontext( fcontext_t * ofc, fcontext_t nfc,
                                               intptr_t vp, bool preserve_fpu = false);

/**
 * @biref 初始化执行环境上下文
 * @param sp 栈空间地址
 * @param size 栈空间的大小
 * @param fn 入口函数
 * @return 返回初始化完成后的执行环境上下文
 */
extern "C" BOOST_CONTEXT_DECL
fcontext_t BOOST_CONTEXT_CALLDECL make_fcontext( void * sp, std::size_t size, void (* fn)( intptr_t) );

}}

然后是现在的API

namespace boost {
namespace context {

/**
 * @biref 执行环境上下文
 */
typedef void*   fcontext_t;

/**
 * @biref 跳转到目标上下文
 * @param ofc 当前的上下文会保存到ofc中
 * @param nfc 跳转到的目标上下文
 * @param vp 跳转到的目标上下文的附加参数。如果是第一次跳转，作为函数参数传入，如果是调回到jump_fcontext，这个是返回值
 * @param preserve_fpu 是否复制FPU（浮点数寄存器）数据
 * @return 如果调回时的透传参数
 */
extern "C" BOOST_CONTEXT_DECL
intptr_t BOOST_CONTEXT_CALLDECL jump_fcontext( fcontext_t * ofc, fcontext_t nfc,
                                               intptr_t vp, bool preserve_fpu = false);

/**
 * @biref 初始化执行环境上下文
 * @param sp 栈空间地址
 * @param size 栈空间的大小
 * @param fn 入口函数
 * @return 返回初始化完成后的执行环境上下文
 */
extern "C" BOOST_CONTEXT_DECL
fcontext_t BOOST_CONTEXT_CALLDECL make_fcontext( void * sp, std::size_t size, void (* fn)( intptr_t) );

}}

namespace boost {
namespace context {
namespace detail {

/**
 * @biref 执行环境上下文
 */
typedef void*   fcontext_t;

/**
 * @biref 事件参数包装
 */
struct transfer_t {
    fcontext_t  fctx; /** 相关的的执行环境上下文-不同的API里含义不一样 **/
    void    *   data; /** 自定义数据 **/
};

/**
 * @biref 跳转到目标上下文
 * @param to 当前的上下文会保存到ofc中
 * @param vp 跳转到的目标上下文的附加参数，会设置为transfer_t里的data成员
 * @return 跳转来源
 */
extern "C" BOOST_CONTEXT_DECL
transfer_t BOOST_CONTEXT_CALLDECL jump_fcontext( fcontext_t const to, void * vp);

/**
 * @biref 初始化执行环境上下文
 * @param sp 栈空间地址
 * @param size 栈空间的大小
 * @param fn 入口函数
 * @return 返回初始化完成后的执行环境上下文
 */
extern "C" BOOST_CONTEXT_DECL
fcontext_t BOOST_CONTEXT_CALLDECL make_fcontext( void * sp, std::size_t size, void (* fn)( transfer_t) );

/**
 * @biref 顶层跳转
 * @param to 当前的上下文会保存到ofc中
 * @param vp 跳转到的目标上下文的附加参数，会设置为transfer_t里的data成员
 * @param fn 入口函数，参数是跳转来源
 * @return 跳转来源
 */
// based on an idea of Giovanni Derreta
extern "C" BOOST_CONTEXT_DECL
transfer_t BOOST_CONTEXT_CALLDECL ontop_fcontext( fcontext_t const to, void * vp, transfer_t (* fn)( transfer_t) );

}}}

流程变化

诸如命名空间从boost转移到boost::detail这种废话我就不说了，这也是说作者不再希望用户直接使用这些接口了。然而这挡不住我非要直接用，哈哈。

重要的是首先API参数和返回值变化，对于这些接口变更，boost里并没有文档，也没有什么地方有说明，所以目前我只能通过它的单元测试和sample来评估功能。

首先重要的是多一个transfer_t，这个里面的有两个对象，第一个fctx是来源的执行上下文，第二个data是各种接口传入的自定义的指针(上面接口里的vp)。来源的上下文指的是从什么位置跳转过来的。无论在回调参数还是各项返回值中都是这个含义。

对于make_fcontext这个接口，原先的入口函数是void (* fn)( intptr_t)，参数是透传自定义指针。现在是void (* fn)( transfer_t)，里面包含了来源执行栈的上下文和透传的自定义指针。

对于jump_fcontext这个接口，原先需要传入把当前执行上下文保存到哪里，跳转目标的新的上下文，自定义数据和是否复制FPU。现在的版本不再需要指定是否需要复制FPU了，同时也去除了自动保存当前上下文的功能，并且改成了跳到新的上下文后，新的上下文可以知道自己是从哪跳转过来的。

简单得说，原来比较像POSIX的makecontext和swapcontext，现在做得事情更少了，功能拆分得更细，那么有些功能就得使用者来写。

另外，这次的boost.context新增了一个比较有意思的接口，transfer_t ontop_fcontext( fcontext_t const to, void * vp, transfer_t ( fn)( transfer_t) )。这个接口的功能是在跳转目标(to指向的上下文)上模拟函数调用，并且返回值作为jump_fcontext*的返回值，相当于可以给执行上下文接口打hook。举个例子：


// Step 1. 当前处于执行上下文-fctx1
transfer_t jump_res = jump_fcontext(fctx2, NULL);

// ...
// Step 2. 当前处于执行上下文-fctx2
// 跳入ontop_callback函数
ontop_fcontext(fctx1, 0x01, ontop_callback);

transfer_t ontop_callback( transfer_t from) {
    // 这时候 from.fctx == fctx2, from.data == 0x01
    // Step 3. 可以改变这些数据
    from.data = 0x02;
    return from;
}

// 这时候返回Step 1的
transfer_t jump_res = jump_fcontext(fctx2, NULL);
// Step 4. 这时候，jump_res.fctx == fctx2, from.data == 0x02
// continue other ...

这个功能比较有意思，execution_context_v2里也使用它来完成初始化和跳转后的数据预处理。不过目前libcopp还没有地方需要用到它，以后有时间再想想这玩意在什么情况下需要用到，然后再加接口。

向前兼容

新的API不再像老的一样，跳转后会自动保存原来的上下文。所以在兼容之前的使用方法的时候，就需要手动来保存一下。boost.context是使用了一个新的对象来记录调用者信息

struct data_t {
    activation_record   *   from;
    void                *   data;
};

那么jump_fcontext和ontop_fcontext的vp参数都是data_t*，然后每次跳入后保存调用来源的上下文

// ========== 调用jump_fcontext ==========
// store current activation record in local variable
auto from = current_rec.get(); // 这是一个TLS变量记录当前执行环境上下文
// store `this` in static, thread local pointer
// `this` will become the active (running) context
// returned by execution_context::current()
current_rec = this; // 更新当前执行环境上下文
// 这一段是对GCC动态栈的支持
#if defined(BOOST_USE_SEGMENTED_STACKS)
// adjust segmented stack properties
__splitstack_getcontext( from->sctx.segments_ctx);
__splitstack_setcontext( sctx.segments_ctx);
#endif
data_t d = { from, vp }; // vp 是外部传入的private data
// context switch from parent context to `this`-context
transfer_t t = jump_fcontext( fctx, & d);
data_t * dp = reinterpret_cast< data_t * >( t.data);
dp->from->fctx = t.fctx; // 保存来源上下文

// ========== 通过jump_fcontext第一次跳入 ==========
// tampoline function
// entered if the execution context
// is resumed for the first time
template< typename AR >
static void entry_func( detail::transfer_t t) noexcept {
    detail::data_t * dp = reinterpret_cast< detail::data_t * >( t.data);
    AR * ar = static_cast< AR * >( dp->data);
    BOOST_ASSERT( nullptr != ar);
    dp->from->fctx = t.fctx; // 保存来源上下文
    // start execution of toplevel context-function
    ar->run();
}

// ========== 调用ontop_fcontext ==========
std::tuple< void *, Fn > p = std::forward_as_tuple( data, fn);
data_t d = { from, & p };
// context switch from parent context to `this`-context
// execute Fn( Tpl) on top of `this`
transfer_t t = ontop_fcontext( fctx, & d, context_ontop< Fn >);
data_t * dp = reinterpret_cast< data_t * >( t.data);
dp->from->fctx = t.fctx; // 保存来源上下文

// ========== 通过ontop_fcontext跳入 ==========
template< typename Fn >
transfer_t context_ontop( transfer_t t) {
    data_t * dp = reinterpret_cast< data_t * >( t.data);
    dp->from->fctx = t.fctx; // 保存来源上下文
    auto tpl = reinterpret_cast< std::tuple< void *, Fn > * >( dp->data);
    BOOST_ASSERT( nullptr != tpl);
    auto data = std::get< 0 >( * tpl);
    typename std::decay< Fn >::type fn = std::forward< Fn >( std::get< 1 >( * tpl) );
    dp->data = apply( fn, std::tie( data) );
    return { t.fctx, dp };
}

看上面的代码，基本上向前兼容的方法就是新搞一个data_t数据记录来源的execution_context的信息，透传过去后再把老的上下文保存进度。并且这么做之后，由于要有方式获取正在进行的上下文是哪一个，它有个记录当前执行上下文的TLS变量就变成了关键的东西。而这个TLS变量的问题后面会再提到。

execution_context_v2

新的boost.context提供了一个新版本的execution_context对象，它其实是针对新的设计模型的一个执行上下文的抽象，并且粒度比以前的更小。所以你可以看到在性能比较的页面里v2版本的性能远高于v1。实际上性能高的原因是execution_context_v1提供了有限的libcopp中coroutine提供的一部分功能，而execution_context_v2则是把这些功能拆分地力度更小，作为其他模块的组件的时候更灵活。如果要使用execution_context_v2的话，一些execution_context_v1处理的问题还是必须上层框架再处理，所以单纯地比较切换速度意义不大。

另外新的execution_context_v2更大规模地使用了C++11的特性，比如noexpect，右值，转移语义等等，用于提升性能。核心代码如下：


/** 参数包装 **/
typedef std::tuple< Args ... >     args_tpl_t;
/** 返回值包装 **/
typedef std::tuple< execution_context, typename std::decay< Args >::type ... >               ret_tpl_t;

/** 用于记录栈地址，入口函数和参数的对象 **/
typedef record< Ctx, StackAlloc, Fn, Params ... >  record_t;

// ========== 调用jump_fcontext - context_create函数内 ==========
// create fast-context
const fcontext_t fctx = make_fcontext( sp, size, & context_entry< record_t >);
BOOST_ASSERT( nullptr != fctx);
// placment new for control structure on context-stack
auto rec = ::new ( sp) record_t{
        sctx, salloc, std::forward< Fn >( fn), std::forward< Params >( params) ... };
// transfer control structure to context-stack
return jump_fcontext( fctx, rec).fctx;

// ========== 调用jump_fcontext - ret_tpl_t operator()( Args ... args)函数内 ==========
ret_tpl_t operator()( Args ... args) {
    BOOST_ASSERT( nullptr != fctx_);
    args_tpl_t data( std::forward< Args >( args) ... );
    detail::transfer_t t = detail::jump_fcontext( detail::exchange( fctx_, nullptr), & data);
    if ( nullptr != t.data) {
        data = std::move( * static_cast< args_tpl_t * >( t.data) );
    }
    return std::tuple_cat( std::forward_as_tuple( execution_context( t.fctx) ), std::move( data) );
}

// ========== 通过jump_fcontext第一次跳入 ==========
template< typename Rec >
void context_entry( transfer_t t_) noexcept {
    // transfer control structure to the context-stack
    Rec * rec = static_cast< Rec * >( t_.data);
    BOOST_ASSERT( nullptr != rec);
    transfer_t t = { nullptr, nullptr };
    try {
        // jump back to `context_create()`
        t = jump_fcontext( t_.fctx, nullptr);
        // start executing
        t = rec->run( t);
    } catch ( forced_unwind const& e) {
        t = { e.fctx, nullptr };
    }
    BOOST_ASSERT( nullptr != t.fctx);
    // destroy context-stack of `this`context on next context
    ontop_fcontext( t.fctx, rec, context_exit< Rec >);
    BOOST_ASSERT_MSG( false, "context already terminated");
}

// ========== 调用ontop_fcontext ==========
template< typename Fn >
ret_tpl_t operator()( exec_ontop_arg_t, Fn && fn, Args ... args) {
    BOOST_ASSERT( nullptr != fctx_);
    args_tpl_t data{ std::forward< Args >( args) ... };
    auto p = std::make_tuple( fn, std::move( data) );       // 透传类型是 std::tuple<Fn, args_tpl_t>
    detail::transfer_t t = detail::ontop_fcontext(
            detail::exchange( fctx_, nullptr),              // 跳入fctx_并把fctx_置空
            & p,
            detail::context_ontop< execution_context, Fn, Args ... >);
    if ( nullptr != t.data) {
        data = std::move( * static_cast< args_tpl_t * >( t.data) );
    }
    return std::tuple_cat( std::forward_as_tuple( execution_context( t.fctx) ), std::move( data) );
}

// ========== 通过ontop_fcontext跳入 ==========
template< typename Ctx, typename Fn, typename ... Args >
transfer_t context_ontop( transfer_t t) {
    auto tpl = static_cast< std::tuple< Fn, std::tuple< Args ... > > * >( t.data);
    BOOST_ASSERT( nullptr != tpl);
    typename std::decay< Fn >::type fn = std::forward< Fn >( std::get< 0 >( * tpl) );
    auto args = std::move( std::get< 1 >( * tpl) );
    Ctx ctx{ t.fctx };
    // execute function
    auto result = apply(                                // apply的作用是展开并调用fn函数： fn(ctx, unpack(args))
            fn,
            std::tuple_cat(
                std::forward_as_tuple( std::move( ctx) ),
                std::move( args) ) );
    ctx = std::move( std::get< 0 >( result) );
    // apply returned data
    detail::tail( args) = std::move( result);
    std::get< 1 >( * tpl) = std::move( args);
    return { exchange( ctx.fctx_, nullptr), & std::get< 1 >( * tpl) };
}

存在的问题

我是不建议使用boost.context的execution_context的。因为首先libcopp本身处理了它完成的功能，虽然它用模板写得，但是本身有一些兼容性问题。

比如TLS的问题，因为默认的Android和IOS标准库不支持TLS，而它里面大量使用thread_local关键字。首先不说非C++11的模式下没有这个关键字，即便有，在Android和IOS的默认标准库下也会link error。对于execution_context用TLS解决的问题，在libcopp里也同时存在，并且我也没想到什么好办法去解决（用pthread_create_key并不是特别理想），所以我现在的做法是，至少Android和IOS下单线程可用，多线程不支持copp::this_XXX功能。

其他不是很重要的变化

这次的版本更新，boost.context也有一些非关键性的变更。之所以说非关键是因为这些东西可有可没有，即便没有的话自己实现也不困难。列举如下:

pooled_fixedsize_stack，现在boost.context自己提供了一个用于分配栈空间的内存池。内部使用了侵入式智能指针，反正libcopp本身能够很容易实现这个，并且benchmark里本身就有使用预定内存池的例子，所以我认为这是非关键的功能。
很多函数重新整理了一下，增加了noexpect/nothrow等。

libcopp的修订

这次的merge，使用新的设计模型是必然的，但与此同时，我也会做一些细节的优化和调整。主要是下面几大块：

优化原来使用spin lock来处理多线程保护，还是抽象出跨平台且比较简单的原子操作类吧。好多时候想用但是因为麻烦直接用了c++11的atomic，但是这货gcc 4.4里没有。
更新接入新API，类似execution_context_v1的方式定义一个新的POD类型作为透传数据(必须是POD因为不会执行析构函数的)，跳转后处理保存来源的执行位置
更新接入新API的话，跳转来源只能靠this_coroutine提供了。原先是对多线程且不支持TLS的环境不能使用this_coroutine，现在基础功能依赖它的话就必须保证其正确。那么计划是VC的话还是必须使用高版本（反正有社区版免费），GCC/Clang之流使用pthread处理TLS吧。
优化 coroutine增加private data，然后this_task可以用this_coroutine关联，不需要两个TLS变量了，这是之前设计的一处小失误。这样task的多线程重入也可以用coroutine的。
更新 caller应该要变为每次入口函数后初始化和不是来自yield的jump_to后更新。基本上caller只需要记录fcontext（支持GCC动态栈的情况下还需要多复制一个动态执行栈的数据），作用也只有执行完成后跳回。如果不是调用yield导致返回的，则是外部主动调用resume，所以结束时也需要返回到主动调用的地方。
更新 start内的jump_to只能通过this_XXX来获取来源协程，yield内的jump_to的来源就是this。每次jump_to返回后都要更新来源协程的callee
更新 this_XXX功能应该是入口函数处设置和jump_to执行返回后刷新（不能由外层记录old，因为可能发生变化）。起新的协程和yield都会走jump_to，同样start内得设为jump_to前的this_XXX，而yield的直接设为this
优化接入cmake的WriteCompilerDetectionHeader并和atframe_utils保持一致，尽量加noexpect
优化整理一下CI配置，同步libatbus的CI配置

预计重构完成后性能不会有太大的改变，甚至因为更多地使用原子操作，可能导致性能还会变低一些。不过毕竟实际运用中并不需要经常做协程切换操作，而且逻辑的复杂度源超协程切换，所以关系不大。但是重构完后使用者更不容易出现错误，并且可以支持协程A跳转到协程B再跳转到协程A这种循环跳转，还是值得的。具体由多大变化，还是等重构完后看测试结果吧。

I'm OWenT

Challenge Everything