非对称协程（asymmetric coroutines）：是跟一个特定的调用者绑定的，协程让出 CPU 时，只能让回给原调用者。那到底是什么东西“不对称”呢？其实，非对称在于程序控制流转移到被调协程时使用的是 call/resume 操作，而当被调协程让出 CPU时使用的却是 return/yield 操作。此外，协程间的地位也不对等，caller 与 callee 关系是确定的，不可更改的，非对称协程只能返回最初调用它的协程。
对称协程（symmetric coroutines）：启动之后就跟启动之前的协程没有任何关系了。协程的切换操作，一般而言只有一个操作，yield，用于将程序控制流转移给另外的协程。对称协程机制一般需要一个调度器的支持，按一定调度算法去选择 yield的目标协程。libco本质上是一种非对称协程，libco 内部为保存协程的调用链留了一个 stack 结构，而这个 stack 大小只有固定的128。使用 libco，如果不断地在一个协程运行过程中启动另一个协程，随着嵌套深度增加就可能会造成这个栈空间溢出。
关键数据结构：
//libco 的协程控制块 stCoRoutine_t
struct stCoRoutine_t
{
//libco 的协程一旦创建之后便跟创建时的那个线程绑定了的，是不支持在不同线程间迁移（migrate）的。这个 env，即同属于一个线程所有协程的执行环境，包括了当前运行协程、上次切换挂起的协程、嵌套调用的协程栈，和一个 epoll 的封装结构（TBD）。
stCoRoutineEnv_t *env; //协程执行的环境
pfn_co_routine_t pfn; //实际待执行的协程函数
void *arg; //实际待执行的协程参数
//ctx 是一个 coctx_t 类型的结构，用于协程切换时保存 CPU 上下文(context）的；所谓的上下文，即esp、ebp、eip和其他通用寄存器的值。
coctx_t ctx;
//状态和标志变量
char cStart;
char cEnd;
char cIsMain;
char cEnableSysHook;
char cIsShareStack;
//用于保存程序系统环境变量的指针
void *pvEnv;
//协程运行时的栈内存char sRunStack[1024 * 128 ];
stStackMem_t* stack_mem;//实现 stackful 协程（与之相对的还有一种 stackless 协程）的两种技术：Separate coroutine stacks 和 Copying the stack(又叫共享栈)。实现细节上，前者为每一个协程分配一个单独的、固定大小的栈；而后者则仅为正在运行的协程分配栈内存，当协程被调度切换出去时，就把它实际占用的栈内存 copy 保存到一个单独分配的缓冲区；当被切出去的协程再次调度执行时，再一次 copy 将原来保存的栈内存恢复到那个共享的、固定大小的栈内存空间。通常情况下，一个协程实际占用的（从 esp 到栈底）栈空间，相比预分配的这个栈大小（比如 libco的128KB）会小得多；这样一来，copying stack 的实现方案所占用的内存便会少很多。当然，协程切换时拷贝内存的开销有些场景下也是很大的。因此两种方案各有利弊，而libco 则同时实现了两种方案，默认使用前者，也允许用户在创建协程时指定使用共享栈。
//在共享栈缓冲区上确认保存stack缓冲区
char* stack_sp;
unsigned int save_size;
char* save_buffer;stCoSpec_t aSpec[1024];
}//保存协程上下文
struct coctx_t：
{
#if defined(__i386__)
void *regs[ 8 ];
#else
void *regs[ 14 ];
#endif
size_t ss_size;
char *ss_sp;
};//这个结构是跟运行的线程绑定了的，运行在同一个线程上的各协程是共享该结构的，是全局性的资源
struct stCoRoutineEnv_t
{
stCoRoutine_t *pCallStack[ 128 ];
int iCallStackSize;
stCoEpoll_t *pEpoll;//记录协程切换时占有共享栈 lastco的和将要切换运行nextco的协程
stCoRoutine_t* pending_co;
stCoRoutine_t* occupy_co;
};
//stCoRoutineEnv_t 结构里的 pCallStack 不是普通意义上的程序运行栈，那个 ESP（RSP）寄存器指向的栈，是用来保留程序运行过程中局部变量以及函数调用关系的。但是，这个 pCallStack 又跟 ESP（RSP）指向的栈有相似之处。如果将协程看成一种特殊的函数，那么这个 pCallStack 就是保存这些函数的调用链的栈。非对称协程最大特点就是协程间存在明确的调用关系；甚至在有些文献中，启动协程被称作 call，挂起协程叫 return。非对称协程机制下的被调协程只能返回到调用者协程，这种调用关系不能乱，因此必须将调用链保存下来。这即是 pCallStack “调用栈”的作用每当启动(resume)一个协程时，就将它的协程控制块 stCoRoutine_t 结构指针保存在 pCallStack 的“栈顶”，然后“栈指针”iCallStackSize 加 1，最后切换 context 到待启动协程运行。当协程要让出(yield)CPU 时，就将它的 stCoRoutine_t 从 pCallStack 弹出，“栈指针”iCallStackSize 减 1，然后切换 context 到当前栈顶的协程(原来被挂起的调用者)恢复执行。
libco 程序的第一个协程呢? 假如第一个协程 yield 时，CPU控制权让给谁呢？首先我们要明白这“第一个”协程是什么。实际上，libco 的第一个协程，即执行 main 函数的协程，是一个特殊的协程。这个协程又可以称作主协程，它负责协调其他协程的调度执行（网络 I/O 以及定时事件的驱动），它自己则永远不会 yield，不会主动让出 CPU。不让出（yield）CPU，不等于说它一直霸占着 CPU。我们知道 CPU 执行权有两种转移途径，一是通过 yield 让给调用者，其二则是 resume 启动其他协程运行。后文我们可以清楚地看到，co_resume()与 co_yield() 都伴随着上下文切换，即 CPU 控制流的转移。当你在程序中第一次调用co_resume() 时，CPU 执行权就从主协程转移到了 resume 目标协程上了。
主协程是在什么时候创建出来的呢？什么时候 resume 的呢？事实上，主协程是跟 stCoRoutineEnv_t 一起创建的。主协程也无需调用 resume 来启动，它就是程序本身，就是 main 函数。主协程是一个特殊的存在，可以认为它只是一个结构体而已。在程序首次调用 co_create() 时，此函数内部会判断当前进程（线程）的 stCoRoutineEnv_t 结构是否已分配，如果未分配则分配一个，同时分配一个 stCoRoutine_t 结构，并将 pCallStack[0] 指向主协程。此后如果用 co_resume() 启动协程，又会将 resume 的协程压入 pCallStack 栈。
在图中，coroutine2 处于栈顶，也就是说，当前正在 CPU 上 运行的协程是coroutine2。coroutine2 的调用者是谁呢？是谁 resume了coroutine2 呢？是 coroutine1。coroutine1 则是主协程启动的，即在 main 函数里 resume 的。当 coroutine2 让出 CPU 时，只能让给 coroutine1；如果 coroutine1 再让出 CPU，那么又回到了主协程的控制流上了。当控制流回到主协程上时，主协程在干些什么呢？main函数最终调用了 co_eventloop()。该函数是一个基于 epoll/kqueue 的事件循环，负责调度其他协程运行，stCoRoutineEnv_t 结构中的 pEpoll 即使在这里使用。
协程的主要函数分析：
创建协程函数：int co_create( stCoRoutine_t **co,const stCoRoutineAttr_t *attr,void *(*routine)(void*),void *arg );
co: stCoRoutine_t** 类型的指针。输出参数，co_create 内部会为新协程分配⼀个“协程控制块”，*ppco 将指向这个分配的协程控制块。
attr: stCoRoutineAttr_t* 类型的指针。输⼊参数，用于指定要创建协程的属性，可为 NULL。实际上仅有两个属性：栈⼤小、指向共享栈的指针（使用共享栈模式）。
outine: void (*)(void*)类型的函数指针，指向协程的任务函数，即启动这个协程后要完成什么样的任务。routine 类型为函数指针。
arg: void* 类型指针，传递给任务函数的参数。调用 co_create 将协程创建出来后，这时候它还没有启动，也即是说我们传递的routine 函数还没有被调用。实质上，这个函数内部仅仅是分配并初始化 stCoRoutine_t结构体、设置任务函数指针、分配一段“栈”内存，以及分配和初始化 coctx_t。为什么这里的“栈”要加个引号呢？因为这里的栈内存，无论是使用预先分配的共享栈，还是co_create 内部单独分配的栈，其实都是调用 malloc 从进程的堆内存分配出来的。对于协程而言，这就是“栈”，而对于底层的进程（线程）来说这只不过是普通的堆内存而已。co_create：协程创建函数
int co_create( stCoRoutine_t **ppco,const stCoRoutineAttr_t *attr,pfn_co_routine_t pfn,void *arg )
{
//判断当前线程的初始化环境变量
if( !co_get_curr_thread_env() )
{
//没进行初始化，调用co_init_curr_thread_env() 进行初始化
co_init_curr_thread_env();
}
//分配一个协程控制块，获取当前线程环境，传入sttr，pfn，arg，创建协程环境
stCoRoutine_t *co = co_create_env( co_get_curr_thread_env(), attr, pfn,arg );
*ppco = co;
return 0;
}
协程初始化函数：void co_init_curr_thread_env() {}
void co_init_curr_thread_env()
{
gCoEnvPerThread = (stCoRoutineEnv_t*)calloc( 1, sizeof(stCoRoutineEnv_t) );
stCoRoutineEnv_t *env = gCoEnvPerThread;env->iCallStackSize = 0;
struct stCoRoutine_t *self = co_create_env( env, NULL, NULL,NULL );
self->cIsMain = 1;env->pending_co = NULL;
env->occupy_co = NULL;coctx_init( &self->ctx );
env->pCallStack[ env->iCallStackSize++ ] = self;
stCoEpoll_t *ev = AllocEpoll();
SetEpoll( env,ev );
}
co_init_curr_thread_env()会生成当前环境g_arrCoEnvPerThread[GetPid()]的第一个协程 env->pCallStack，其 cIsMain 标志位 1，iCallStackSize表示协程层数，目前只有1层，AllocEpoll()函数中初始化当前环境env的 pstActiveList、pstTimeoutList 这两个列表，这两个列表分别记录了活动协程和超时协程。环境初始化操作在一个线程中只会进行一次。在初始化完成之后，会调用co_create_env()创建一个新的协程，新协程的结构体中的env这个域始终指向当前协程环境g_arrCoEnvPerThread[ GetPid() ]。新协程创建之后，并没有做什么操作。
启动协程函数：void co_resume( stCoRoutine_t *co );
启动 co 指针指向的协程。libco 的协程是非对称协程，协程在让出CPU 后要恢复执行的时候，还是要再次调用co_resume 函数的去“启动”协程运行的。从语义上来讲，co_start 只有一次，而 co_resume 可以是暂停之后恢复启动，可以多次调用。讲到非对称协程，一般用“resume”与“yield”这两个术语。协程要获得 CPU 执行权用“resume”，而让出 CPU 执行权用“yield”，这两个是两个不同的（不对称的）过程，因此这种机制才被称为非对称协程（asymmetric coroutines）。所以讲到 resume 一个协程，我们一定得注意，这可能是第一次启动该协程，也可以是要准备重新运行挂起的协程。我们可以认为在 libco 里面协程只有两种状态，即running 和 pending。当创建一个协程并调用 resume 之后便进入了 running 状态，之后协程可能通过 yield 让出 CPU，这就进入了 pending 状态。不断在这两个状态间循环往复，直到协程退出（执行的任务函数 routine 返回）
co_resume() 启动一个协程的含义，不是“创建一个并发任务”。进入 co_resume() 函数后发生协程的上下文切换，协程的任务函数是立即就会被执行的，而且这个执行过程不是并发的（Concurrent）。为什么不是并发的呢？因为 co_resume() 函数内部会调用 coctx_swap() 将当前协程挂起，然后就开始执行目标协程的代码了。本质上这个过程是串行的，在一个操作系统线程（进程）上发生的，甚至可以说在一颗 CPU 核上发生的。将 coroutine 当做一种特殊的subroutine 来看：A 协程调用 co_resume(B) 启动了 B 协程，本质上是一种特殊的过程调用关系，A 调用 B 进入了 B 过程内部，这很显然是一种串行执行的关系。既然 co_resume() 调用后进入了被调协程执行控制流，那么 co_resume()函数本身何时返回？这就要等被调协程主动让出 CPU 了。
co_resume：启动协程函数
void co_resume( stCoRoutine_t *co )
{
stCoRoutineEnv_t *env = co->env;
stCoRoutine_t *lpCurrRoutine = env->pCallStack[ env->iCallStackSize - 1 ];
if( !co->cStart )
{
coctx_make( &co->ctx,(coctx_pfn_t)CoRoutineFunc,co,0 );
co->cStart = 1;
}
env->pCallStack[ env->iCallStackSize++ ] = co;
co_swap( lpCurrRoutine, co );
}第2行是获取当前线程的协程环境env，第3行获取当前正在执行的协程，也即马上要被切换出去的协程。第 5、6 行的 if 条件分支用来判断待切换的协程co是否已经被切换过，当且仅当协程是第一次启动时才会执行到，首次启动协程过程有点特殊，需要调用 coctx_make() 为新协程准备 context上下文（为了让 co_swap() 内能跳转到协程的任务函数），并将 cStart 标志变量置 1。这里为新协程co准备的上下文，就是在coctx_make()函数里面,这个函数将函数指针CoRoutineFunc赋值给co->ctx的reg[0],将来上下文切换的时候,就能切换到reg[0]所指向的地址去执行。第 8 行将将待切换的协程co 压入 pCallStack 栈，置于协程环境env的协程栈的顶端，表明当前最新的协程是co。最后，调用co_swap()，函数将协程上下文环境切换为新协程co的上下文环境，并进入新协程co指定的函数内执行，之前被切换出去的协程被挂起，直到新协程co主动yield，让出cpu，才会恢复被切换出去的协程执行。
所有的协程都是在当前协程执行的，也就是说，所有的协程都是串行执行的，调用co_resume()之后，执行上下文就跳到新协程co的代码空间中去了。co_swap() 不会就此返回，这次 resume 的 新协程co 协程内部可能会resume新的协程继续执行下去，因此直到这次的新协程co主动yield 让出 CPU 时才会返回到co_resume() 中来所以co_swap()函数调用可能要等到很长时间才能返回。值得指出的是，这里讲 co_swap() 不会就此返回，不是说这个函数就阻塞在这里等待 co 这个协程 yield 让出 CPU，实际上co_swap() 内部已经切换了 CPU 执行上下文，奔着新协程co的代码路径去执行了。
挂起协程函数：void co_yield( stCoRoutine_t *co );
void co_yield_env( stCoRoutineEnv_t *env );
void co_yield_ct(); //ct = current thread
void co_yield( stCoRoutine_t *co )
{
co_yield_env( co->env );
}
void co_yield_env( stCoRoutineEnv_t *env )
{
stCoRoutine_t *last = env->pCallStack[ env->iCallStackSize - 2 ];
stCoRoutine_t *curr = env->pCallStack[ env->iCallStackSize - 1 ];
env->iCallStackSize--;
co_swap( curr, last);
}
在调用co_yield_env()，进入co_swap()之后，调用coctx_swap()，切换到上一次的last协程的上下文，那么当前协程的co_swap()函数里面的变量，都是在栈空间上面的，切换到last协程的上下文之后，那些变量依然在栈空间上面，不会被销毁？直到回到了main函数的协程，还是没有被销毁？。
其实这些变量其实不是在栈空间上面，而是在CPU的通用寄存器里面，当调用coctx_swap()之后，这些寄存器变量就会保存到当前协程的栈空间中去，其实是我们之前co_create()函数malloc出来的一片堆空间。这是因为cpu的工作寄存器数量较多，而局部变量较少，而co_swap()函数的变量都是局部变量，直接存放在cpu的工作寄存器中，而coctx_swap()的作用就是将CPU的各个通用寄存器保存到coctx_t结构的regs[1] ~ regs[6]的位置，然后将last协程的coctx_t结构的regs[1]~regs[6]的内容加载到当前的通用寄存器中，并将执行cpu的执行顺序切换到last协程中去执行。在非对称协程理论，yield 与 resume 是个相对的操作。A 协程 resume 启动了 B 协程，那么只有当 B 协程执行 yield 操作时才会返回到 A 协程。当协程正常结束的时候,会继续执行CoRoutineFunc()函数,将协程的cEnd设置为1,表示已经结束,并执行一次co_yield_env(),让出cpu,切换回上一次被让出的协程继续执行。函数 co_resume() ,内部 co_swap() 会执行被调协程的代码。只有被调协程 yield 让出 CPU，调用者协程的 co_swap() 函数才能返回到原点，即返回到原来co_resume() 内的位置。在被调协程要让出 CPU 时，会将它的 stCoRoutine_t 从pCallStack 弹出，“栈指针”iCallStackSize 减 1，然后 co_swap() 切换 CPU 上下文到原来被挂起的调用者协程恢复执行。这里“被挂起的调用者协程”，即是调用者 co_resume()中切换 CPU 上下文被挂起的那个协程。
co_resume 是有明确目的对象的，而且可以通过 resume 将 CPU 交给任意协程。但 yield 则不一样，你只能 yield 给当前协程的调用者。而当前协程的调用者，即最初 resume 当前协程的协程，是保存在 stCoRoutineEnv_t的 pCallStack 中的。因此你只能 yield 给“env”，yield 给调用者协程；而不能随意 yield给任意协程，CPU 不是你想让给谁就能让给谁的。事实上，libco 提供了一个 co_yield(stCoRoutine_t* co) 的函数。看起来你似乎可以将CPU 让给任意协程。实际上并非如此：
void co_yield( stCoRoutine_t *co )
{
co_yield_env( co->env );
}
我们知道，同一个线程上所有协程是共享一个 stCoRoutineEnv_t 结构的，因此任意协程的 co->env 指向的结构都相同。如果你调用 co_yield(co)，就以为将 CPU 让给 co 协程了，那就错了。最终通过 co_yield_env() 还是会将 CPU 让给原来启动当前协程的调用者。libco 的协程是不支持线程间迁移（migration）的，同一个线程上所有协程共享 stCoRoutineEnv_t，那么co_yield() 给其他线程上的协程,程序一定会挂掉。这个 co_yield() 其实容易让人产生误解的，协程库内虽然提供了 co_yield(stCoRoutine_t* co) 函数，但是没有任何地方有调用过该函数。使用的较多的是另外一个函数co_yield_ct()，其实本质上作用都是一样的。
/*void co_yield_ct()
{
co_yield_env( co_get_curr_thread_env() );
}stCoRoutineEnv_t *co_get_curr_thread_env()
{
return gCoEnvPerThread;
}static __thread stCoRoutineEnv_t* gCoEnvPerThread = NULL;
void co_init_curr_thread_env()
{
gCoEnvPerThread = (stCoRoutineEnv_t*)calloc( 1, sizeof(stCoRoutineEnv_t) );
stCoRoutineEnv_t *env = gCoEnvPerThread;
......
}*/
切换协程函数：void co_swap(stCoRoutine_t* curr, stCoRoutine_t* pending_co){}
curr ：当前协程的 coctx_t结构指针，输出参数，函数调用过程中会将当前协程的 context 保存在这个参数指向的内存里
pending：即待切入的协程的 coctx_t 指针，输入参数，coctx_swap 从这里取上次保存的 context，恢复各寄存器的值。
coctx_t 结构：用于保存各寄存器值（context）
co_swap函数奇特之处，在于调用之前还处于第一个协程的环境，该函数返回后，则当前运行的协程就已经完全是第二个协程了。void co_swap(stCoRoutine_t* curr, stCoRoutine_t* pending_co)
{
stCoRoutineEnv_t* env = co_get_curr_thread_env();//get curr stack sp
char c;
curr->stack_sp= &c;if (!pending_co->cIsShareStack)
{
env->pending_co = NULL;
env->occupy_co = NULL;
}
else
{
env->pending_co = pending_co;
//get last occupy co on the same stack mem
stCoRoutine_t* occupy_co = pending_co->stack_mem->occupy_co;
//set pending co to occupy thest stack mem;
pending_co->stack_mem->occupy_co = pending_co;env->occupy_co = occupy_co;
if (occupy_co && occupy_co != pending_co)
{
save_stack_buffer(occupy_co);
}
}//swap context
coctx_swap(&(curr->ctx),&(pending_co->ctx) );//stack buffer may be overwrite, so get again;
stCoRoutineEnv_t* curr_env = co_get_curr_thread_env();
stCoRoutine_t* update_occupy_co = curr_env->occupy_co;
stCoRoutine_t* update_pending_co = curr_env->pending_co;
if (update_occupy_co && update_pending_co && update_occupy_co != update_pending_co)
{
//resume stack buffer
if (update_pending_co->save_buffer && update_pending_co->save_size > 0)
{
memcpy(update_pending_co->stack_sp, update_pending_co->save_buffer, update_pending_co->save_size);
}
}
}
//在co_swap()函数代码中，由于libco不是共享栈的模式，即pending_co->cIsShareStack为0，所以执行了if分支，接下来执行coctx_swap()，这是一段汇编源码，内容就是从curr的上下文跳转到pending_co的上下文中执行,通过回调CoRoutineFunc()函数实现，此时当前线程的cpu已经开始执行pending_co协程中的代码,直到pending_co主动让出cpu,才接着执行coctx_swap()下面的代码,由于update_occupy_co为NULL,下面的if语句没有执行,所以相当于coctx_swap()下面没有代码,直接返回到curr协程中
coctx_swap的汇编详解：
.globl coctx_swap
#if !defined( __APPLE__ ) && !defined( __FreeBSD__ )
.type coctx_swap, @function
#endif
coctx_swap:#if defined(__i386__)
//LEA 指令即 Load Effective Address 的缩写。这条指令把 4(%esp) 有效地址保存到 eax 寄存器，可以认为是将当前的栈顶地址保存下来（实际保存的地址比栈顶还要⾼ 4 字节，为了⽅便我们就称之为栈顶）。为什么要保存栈指针呢，因为紧接着就要进⾏栈切换了。
leal 4(%esp), %eax //sp//此时4(%esp) 内正是指向 current 协程 coctx_t 的指针，这里把它塞到 esp 寄存器。接下来将 coctx_t 指针指向的地址加上 32 个字节的内存位置加载到 esp 中。经过这么一倒腾，esp 寄存器实际上指向了当前协程 coctx_t 结构的 ss_size 成员位置，在它之下有个名为 regs 的数组，刚好是用来保存 8 个寄存器值的。注意这是第⼀次栈切换，不过是临时性的，目的只是⽅便接下来使用 push 指令保存各寄存器值。
movl 4(%esp), %esp
leal 32(%esp), %esp //parm a : ®s[7] + sizeof(void*)//eax 寄存器内容压栈。更准确的讲，是将 eax 寄存器保存到了 coctx_t->regs[7] 的位置。注意到eax 寄存器已经保存了原栈顶的地址，所以这句实际上是将当前协程栈顶保存起来，以备下次调度回来时恢复栈地址。
pushl %eax //esp ->parm a
//保存各通用寄存器的值，到 coctx_t 结构的 regs[1]~regs[6] 的位置。
pushl %ebp
pushl %esi
pushl %edi
pushl %edx
pushl %ecx
pushl %ebx
//-4(%eax) 实际上是指向原来 coctx_swap 刚进来时的栈顶，我们讲过栈顶的值是 call 指令自动压⼊的函数返回地址。这句实际上就是将 coctx_swap 的返回地址给保存起来了，放在coctx_t->regs[0] 的位置。
pushl -4(%eax)//⾄此，current 协程的各重要寄存器都已保存完成了，开始可以放⼼地交班给 pending 协程了。接下来我们需要将 pending 协程调度起来运⾏，就需要为它恢复context——恢复各通用寄存器的值以及栈指针。因此这⼀⾏将栈指针切到 pending 协程的 coctx_t 结构体开始，即 regs[0] 的位置，为恢复寄存器值做好了准备。
movl 4(%eax), %esp //parm b -> ®s[0]
//弹出 regs[0] 的值到 eax 寄存器。regs[0] 正该协程上次被切换出去时在第 19 ⾏保存的值，即 coctx_swap 的返回地址。
popl %eax //ret func addr
//从 regs[1]~regs[6] 恢复各寄存器的值（与之相应的是前面第 13~18 ⾏的压栈操作）
popl %ebx
popl %ecx
popl %edx
popl %edi
popl %esi
popl %ebp
//将 pending 协程上次切换出去时的栈指针恢复（与之对应的是第 12 ⾏压栈操作）。请思考⼀下，栈内容已经完全恢复了吗？注意到第 8 ⾏我们讲过，当时保存的“栈顶”比真正的栈顶差了⼀个 4 字节的偏移。⽽这 4 字节真正栈顶的内容，正是coctx_swap 的返回地址。如果此时程序就执⾏ ret 指令返回，那程序就不知道会跑到哪去了。
popl %esp
//为了程序能正确地返回原来的coctx_swap调用的地⽅，将eax 内容（第19⾏保存⾄regs[7]，第23⾏取出来到eax）压栈。
pushl %eax //set ret func addr//清零eax 寄存器，执⾏返回指令
xorl %eax, %eax
ret//一共切换了 3 次栈指针
co_release：释放资源避免内存泄漏
void co_release( stCoRoutine_t *co )
{
if( co->cEnd )
{
free( co );
}
}
co_self：获取当前正在执行的协程，获取当前协程环境的线程栈顶的协程
stCoRoutine_t *co_self()
{
return GetCurrThreadCo();
}stCoRoutine_t *GetCurrThreadCo( )
{
stCoRoutineEnv_t *env = co_get_curr_thread_env();
if( !env ) return 0;
return GetCurrCo(env);
}stCoRoutine_t *GetCurrCo( stCoRoutineEnv_t *env )
{
return env->pCallStack[ env->iCallStackSize - 1 ];
}libco封装了系统调用，在系统调用，比如send/recv/condition_wait等函数前面加了一层hook,有了这层hook就可以在系统调用的时候不让线程阻塞而产生线程切换，co_enable_hook_sys()函数允许协程hook，当然也可以不允许hook，直接使用原生的系统调用。
co_enable_hook_sys：
void co_enable_hook_sys()
{
stCoRoutine_t *co = GetCurrThreadCo();
if( co )
{
co->cEnableSysHook = 1;
}
}
307
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
