Lua 5.3 源码分析（十）线程的执行与中断

Lua 的程序运行时以线程为单位的。每个Lua 线程可以独立运行直到自行中断，把中断的信息留在状态机中。每条线程的执行互不干扰，可以独立延续之前中断的执行过程。

Lua 线程和系统线程无关，所以不会为每条 Lua 线程创建独立的系统堆栈，而是利用自己维护的线程栈，内存开销也就远小于系统线程。

Lua 是一门嵌入式语言，和 C 语言混合编程是一种常态。 一旦Lua 调用的 C 库中企图中断线程，延续它就是一个巨大的难题。

异常处理

如果Lua 被实现为一个纯粹的运行在字节码 VM 上的语言，只要不出 VM，可以很容易的实现自己的线程和异常处理。

事实上，Lua 的函数调用层次上只要没有 C 函数，是不会在 C 层面的调用栈上深入下去的。

但当Lua 函数调用了 C 函数，而这个 C 函数又进一步回调了 Lua 函数，这个问题就复杂很多。

Lua 的标准库中的 pairs 函数，就是一个典型的 C 扩展函数，却又回调了 Lua 函数。

Lua 底层把异常和线程中断用同一种机制来处理，也就是使用了 C 语言标准的 longjmp 机制来解决这个问题。
#if !defined(LUAI_THROW) /* { */

#if defined(__cplusplus) && !defined(LUA_USE_LONGJMP)   /* { *//* C++ exceptions */#define LUAI_THROW(L,c)     throw(c)#define LUAI_TRY(L,c,a) \try { a } catch(...) { if ((c)->status == 0) (c)->status = -1; }#define luai_jmpbuf     int  /* dummy variable */#elif defined(LUA_USE_POSIX)                /* }{ *//* in POSIX, try _longjmp/_setjmp (more efficient) */#define LUAI_THROW(L,c)     _longjmp((c)->b, 1)#define LUAI_TRY(L,c,a)     if (_setjmp((c)->b) == 0) { a }#define luai_jmpbuf     jmp_buf#else                           /* }{ *//* ISO C handling with long jumps */#define LUAI_THROW(L,c)     longjmp((c)->b, 1)#define LUAI_TRY(L,c,a)     if (setjmp((c)->b) == 0) { a }#define luai_jmpbuf     jmp_buf#endif                          /* } */#endif                          /* } */

每条线程 L 中保存了当前的 longjmp 返回点： errorJmp ，其结构定义 为 struct lua_longjmp 。这是一条链表，每次运行一段受保护的 Lua 代码，都会生成一个新的错误返回点，链到这条链表上。

/* chain list of long jump buffers */struct lua_longjmp {    struct lua_longjmp *previous;    luai_jmpbuf b;    volatile int status;  /* error code */};

设置 longjmp 返回点是由 luaD_rawrunprotected 完成的。

int luaD_rawrunprotected (lua_State *L, Pfunc f, void *ud) {    unsigned short oldnCcalls = L->nCcalls;    struct lua_longjmp lj;    lj.status = LUA_OK;    lj.previous = L->errorJmp;  /* chain new error handler */    L->errorJmp = &lj;    LUAI_TRY(L, &lj,             (*f)(L, ud);             );    L->errorJmp = lj.previous;  /* restore old error handler */    L->nCcalls = oldnCcalls;    return lj.status;}

这段代码很容易理解：设置新的 jmpbuf，串到链表上，调用函数。调用完成后恢复进入时状态。
如果想回直接返回到最近的错误恢复点，只需要调用 longjmp。Lua 使用一个内部API luaD_throw 封装了这个过程。

l_noret luaD_throw (lua_State *L, int errcode) {    if (L->errorJmp) {  /* thread has an error handler? */        L->errorJmp->status = errcode;  /* set status */        LUAI_THROW(L, L->errorJmp);  /* jump to it */    }    else {  /* thread has no error handler */        global_State *g = G(L);        L->status = cast_byte(errcode);  /* mark it as dead */        if (g->mainthread->errorJmp) {  /* main thread has a handler? */            setobjs2s(L, g->mainthread->top++, L->top - 1);  /* copy error obj. */            luaD_throw(g->mainthread, errcode);  /* re-throw in main thread */        }        else {  /* no handler at all; abort */            if (g->panic) {  /* panic function? */                seterrorobj(L, errcode, L->top);  /* assume EXTRA_STACK */                if (L->ci->top < L->top)                    L->ci->top = L->top;  /* pushing msg. can break this invariant */                lua_unlock(L);                g->panic(L);  /* call panic function (last chance to jump out) */            }            abort();        }    }}

考虑到新构造的线程可能在不受保护的情况下运行。这时的任何错误都必须被捕获，不能让程序崩溃。这种情况合理的处理方式就是把正在运行的线程标记为死线程，并且在主线程中抛出异常。

函数调用

函数调用分为受保护调用和不受保护的调用。
受保护的函数调用可以看到一个 C 层面意义上完整的过程。在Lua 代码中，pcall 是用函数而不是语音机制完成的。受保护的函数调用一定在 C 层面进出一次调用栈。
它使用一个独立的内部API luaD_pcall 来实现。公开 API luaD_pcallk 仅仅是对它做了一些封装。

int luaD_pcall (lua_State *L, Pfunc func, void *u,                ptrdiff_t old_top, ptrdiff_t ef) {    int status;    CallInfo *old_ci = L->ci;    lu_byte old_allowhooks = L->allowhook;    unsigned short old_nny = L->nny;    ptrdiff_t old_errfunc = L->errfunc;    L->errfunc = ef;    status = luaD_rawrunprotected(L, func, u);    if (status != LUA_OK) {  /* an error occurred? */        StkId oldtop = restorestack(L, old_top);        luaF_close(L, oldtop);  /* close possible pending closures */        seterrorobj(L, status, oldtop);        L->ci = old_ci;        L->allowhook = old_allowhooks;        L->nny = old_nny;        luaD_shrinkstack(L);    }    L->errfunc = old_errfunc;    return status;}

从这段代码我们可以看到 pcall 的处理模式：用 C 层面的堆栈来保护和恢复状态。
L->ci、L->allowhook、L->nny（ nny 的全称是 number of
non-yieldable calls。由于 C 语言本身无法提供延续点的支持，所以 Lua 也无法让所有函数都是 yieldable 的。当一级函数处于 non-yieldable 状态时，更深的层次都无法 yieldable。这个变量用于监督这个状态，在错误发生报告。每级 C 调用是否允许 yield 取决于是否有设置 C 延续点，或是 Lua 内核实现时认为这次调用在发生 yield 时无法正确处理。这些都是由 luaD_call 的最后一个参数来制定。）、L->errfunc 都保存在 luaD_pcall 的 C 堆栈上，一旦 luaD_rawrunprotected 就可以正确恢复。

luaD_rawrunprotected 没有正确返回时，需要根据 old_top 找到堆栈上刚才调用的函数，给它做收尾工作（调用luaF_close 涉及 upvalue 的 gc 流程）。

因为 luaD_rawrunprotected 调用的是一个函数对象，而不是数据栈上的索引，这就需要额外的变量来定位了。

这里使用 restorestack 这个宏来定位栈上的地址，是因为数据栈的内存地址是会随着数据栈的大小而变化。保存地址是不可能的，而应该记住一个相对量。 savestack 和 restorestack这两个宏就是做这个工作的。
#define savestack(L,p) ((char )(p) - (char )L->stack)
#define restorestack(L,n) ((TValue )((char )L->stack + (n)))

一般的 Lua 层面的函数调用并不对应一个 C 层面上函数调用行为。对于Lua 函数而言，应该看成是生成新的 CallInfo，修正数据栈，然后把字节码的执行位置调整到被调用的函数开头。而Lua 函数的return 操作则做了 相反的操作，恢复数据栈，弹出 CallInfo ，修改字节码的执行位置，恢复到原有的执行序列上。

理解了这一点就能明白，在底层 API 中，为何分为 luaD_precall 和 luaD_poscall 。

luaD_precall 执行的是函数调用部分的工作，而 luaD_poscall 做的是函数返回的工作。

从 C 层面看，层层函数调用的过程并不是递归的。对于C 类型的函数调用，整个函数调用时完整的，不需要等待后续再调用 luaD_poscall，所以 luaD_precall 可以替代完成，并返回1； 而Lua 函数，执行完 luaD_precall 后，只是切换了 lua_State 的执行状态，被调用的函数的字节码尚未运行，luaD_precall 返回 0。待到Lua VM 执行到对应的 OP_RETURN 指令时，才会去调用 luaD_poscall 完成整次调用。

call

/* ** returns true if function has been executed (C function) */int luaD_precall (lua_State *L, StkId func, int nresults) {    lua_CFunction f;    CallInfo *ci;    int n;  /* number of arguments (Lua) or returns (C) */    ptrdiff_t funcr = savestack(L, func);    switch (ttype(func)) {        case LUA_TLCF:  /* light C function */            f = fvalue(func);            goto Cfunc;        case LUA_TCCL: {  /* C closure */            f = clCvalue(func)->f;        Cfunc:            luaD_checkstack(L, LUA_MINSTACK);  /* ensure minimum stack size */            ci = next_ci(L);  /* now 'enter' new function */            ci->nresults = nresults;            ci->func = restorestack(L, funcr);            ci->top = L->top + LUA_MINSTACK;            lua_assert(ci->top <= L->stack_last);            ci->callstatus = 0;            luaC_checkGC(L);  /* stack grow uses memory */            if (L->hookmask & LUA_MASKCALL)                luaD_hook(L, LUA_HOOKCALL, -1);            lua_unlock(L);            n = (*f)(L);  /* do the actual call */            lua_lock(L);            api_checknelems(L, n);            luaD_poscall(L, L->top - n);            return 1;        }        case LUA_TLCL: {  /* Lua function: prepare its call */            StkId base;            Proto *p = clLvalue(func)->p;            n = cast_int(L->top - func) - 1;  /* number of real arguments */            luaD_checkstack(L, p->maxstacksize);            for (; n < p->numparams; n++)                setnilvalue(L->top++);  /* complete missing arguments */            if (!p->is_vararg) {                func = restorestack(L, funcr);                base = func + 1;            }            else {                base = adjust_varargs(L, p, n);                func = restorestack(L, funcr);  /* previous call can change stack */            }            ci = next_ci(L);  /* now 'enter' new function */            ci->nresults = nresults;            ci->func = func;            ci->u.l.base = base;            ci->top = base + p->maxstacksize;            lua_assert(ci->top <= L->stack_last);            ci->u.l.savedpc = p->code;  /* starting point */            ci->callstatus = CIST_LUA;            L->top = ci->top;            luaC_checkGC(L);  /* stack grow uses memory */            if (L->hookmask & LUA_MASKCALL)                callhook(L, ci);            return 0;        }        default: {  /* not a function */            luaD_checkstack(L, 1);  /* ensure space for metamethod */            func = restorestack(L, funcr);  /* previous call may change stack */            tryfuncTM(L, func);  /* try to get '__call' metamethod */            return luaD_precall(L, func, nresults);  /* now it must be a function */        }    }}

Light C function 和 C closure 仅仅是在存储上有所不同，处理逻辑是一致的：压入新的 CallInfo，把数据栈栈顶设置好。调用 C 函数，然后 luaD_poscall。

Lua 函数要复杂一些： 先通入函数对象在数据栈上的位置和栈顶差，计算出数据栈上的调用参数个数 n 。 如果 Lua 函数对输入参数个数有明确的最小要求，这点可以通过查询函数原型 numparams 字段获知； 如果 栈上提供的参数数量不足，就需要把不足的部分补为 nil。 当调用函数需要可变参数的时候，还需要进一步处理：

static StkId adjust_varargs (lua_State *L, Proto *p, int actual) {    int i;    int nfixargs = p->numparams;    StkId base, fixed;    lua_assert(actual >= nfixargs);    /* move fixed parameters to final position */    luaD_checkstack(L, p->maxstacksize);  /* check again for new 'base' */    fixed = L->top - actual;  /* first fixed argument */    base = L->top;  /* final position of first argument */    for (i=0; i<nfixargs; i++) {        setobjs2s(L, L->top++, fixed + i);        setnilvalue(fixed + i);    }    return base;}

变长参数表这个概念，只在Lua 函数中出现。当一个函数接收变长参数时，这部分的参数是放在 上一级数据栈帧尾部。 adjust_varargs 将需要固定参数复制到被调用的函数的新一级数据栈帧上，而变长参数留在原地。

接下来，要构造出新的一层调用栈 CallInfo。这个结构需要初始化字节码执行指针 savepc ，将其指向Lua 函数对象中的 字节指令区。

Lua 函数 整体所需要的栈空间是在生成字节码时就已知的，所以可以用 luaD_checkstack 一次性分配好。 CallInfo 中的栈顶可以直接调整到位。CallInfo 中的返回参数个数，所引用的函数对象一一初始化完毕，最后初始化线程运行状态 callstatus ，标记上 CIST_LUA 就够了。

真正如何运行 Lua 函数，是由调用 luaD_precall 者决定的。
有些对象是通过元表驱动函数调用的行为的，这时需要通过 tryfuncTM 函数取得真正的调用函数。

static void tryfuncTM (lua_State *L, StkId func) {    const TValue *tm = luaT_gettmbyobj(L, func, TM_CALL);    StkId p;    if (!ttisfunction(tm))        luaG_typeerror(L, func, "call");    /* Open a hole inside the stack at 'func' */    for (p = L->top; p > func; p--)        setobjs2s(L, p, p-1);    L->top++;  /* slot ensured by caller */    setobj2s(L, func, tm);  /* tag method is the new function to be called */}

根据Lua 的定义，通过元方法进行的函数调用和原生的函数调用有所区别。通过元方法进行的函数调用，会将对象自身作为第一个参数传入。这就需要移动数据栈，把对象插到第一个参数的位置。这个过程在源代码中有清晰的展示。

return

luaD_poscall 做的工作很简单，主要是数据栈的调整工作。

int luaD_poscall (lua_State *L, StkId firstResult) {    StkId res;    int wanted, i;    CallInfo *ci = L->ci;    if (L->hookmask & (LUA_MASKRET | LUA_MASKLINE)) {        if (L->hookmask & LUA_MASKRET) {            ptrdiff_t fr = savestack(L, firstResult);  /* hook may change stack */            luaD_hook(L, LUA_HOOKRET, -1);            firstResult = restorestack(L, fr);        }        L->oldpc = ci->previous->u.l.savedpc;  /* 'oldpc' for caller function */    }    res = ci->func;  /* res == final position of 1st result */    wanted = ci->nresults;    L->ci = ci = ci->previous;  /* back to caller */    /* move results to correct place */    for (i = wanted; i != 0 && firstResult < L->top; i--)        setobjs2s(L, res++, firstResult++);    while (i-- > 0)        setnilvalue(res++);    L->top = res;    return (wanted - LUA_MULTRET);  /* 0 iff wanted == LUA_MULTRET */}

根据 luaD_precall 设置在CalInfo 里的返回参数的个数 nresult，以及数据栈上在这次函数调用中实际新增的数据个数，需要对数据栈做一次调整。多余的抛弃，不足的补为 nil。

luaD_call

luaD_call 主要用来实现外部 API lua_callk。它调用完 luaD_precall 后，接着调用 luaV_execute 完成对函数本身的字节码执行。

luaD_call 的最后一个参数用来标示这次调用是否可以在其中挂起。因为在 Lua VM 执行期间，有许多情况都会引起新的一层 C 层面的函数调用。

Lua 线程并不拥有独立的 C 堆栈，所以对于发生在 C 函数内部的线程挂起操作，不是所有情况都正确处理的。是否接受 yield 操作，只有调用 luaD_call 才清楚。

void luaD_call (lua_State *L, StkId func, int nResults, int allowyield) {    if (++L->nCcalls >= LUAI_MAXCCALLS) {        if (L->nCcalls == LUAI_MAXCCALLS)            luaG_runerror(L, "C stack overflow");        else if (L->nCcalls >= (LUAI_MAXCCALLS + (LUAI_MAXCCALLS>>3)))            luaD_throw(L, LUA_ERRERR);  /* error while handing stack error */    }    if (!allowyield)        L->nny++;    if (!luaD_precall(L, func, nResults))  /* is a Lua function? */        luaV_execute(L);  /* call it */    if (!allowyield)        L->nny--;    L->nCcalls--;}

如前面所述，Lua VM 在解析字节码执行的过程中，对 Lua 函数的调用并不直接使用 luaD_call。它不会产生 C 层面的函数调用行为，就可以尽量不引起 C 函数中挂起线程的问题。但在某些情况上的处理，也这么做的话会让 VM 的实现变得相当复杂。这些情况包括 for 语句引起的函数调用以及触发元方法引起的函数调用。Lua 利用 luaD_call ，可以简化实现。

从 C 函数中挂起线程

如何让 C 函数正确的配合工作？

C 语言是不支持延续点这个特性的。如果你从 C 函数中利用 longjmp 跳出，就再也回不到跳出点了。这对 Lua 工作在 VM 字节码上的大部分特性都不是问题。

但是，pcall 和元表 都涉及 C 函数调用，有这样的限制，让 Lua 不那么完整。Lua 应用一系统的技巧，绕开了这个限制，支持了 yieldable pcall and metamethods。

在Lua 文档中，可以找到这么一小节： Handing Yields in C 就是围绕解决这个难题展开的。首先我们来看问题的产生：
resume 的发起总是通过一次 lua_resume 的调用，在 Lua5.1 以前，yield 的调用必定结束于一次 lua_yield 调用，而调用它的 C 函数必须立刻返回。中间不能有任何 C 函数执行到中途的状态。这样，Lua VM 才能正常工作。
(C) lua_resume -> Lua functions -> coroutine.yield -> (C) lua yield -> (C) return
在这个流程中，无论Lua functions 有多少层，都被 lua_State 的调用栈管理。所以当最后 C return 返回到最初 resume 点，都不存在什么问题，可以让下一次 resume 正确继续。 也就是说，在 yield 时， Lua 调用栈上可以有 没有执行完的 Lua 函数，但不可以有 没有执行完的 C 函数。

如果我们写了一个 C 扩展， 在 C function 里回调了传入的一个 Lua 函数。情况就变得不一样了。
(C) lua_resume -> Lua function -> C function -> (C) lua_call -> Lua function -> coroutine.yield -> (C) lua_yield
C 通过 lua_call 调用的 Lua 函数中再调用 coroutine.yield 会导致 在 yield 之后， 再次 resume 时，不再可能从 lua_call 的下一行继续执行。 Lua 在遇到这种情况时，会抛出一个异常“attempt to yield across a C-call boundary”

在 C 和 Lua 的边界，如果在 yield 之后，resume 如何继续运行 C 边界之后的 C 代码？
所有 Lua 协程共享一个 C 堆栈。可以使用 longjmp 从调用深处跳出来，却无法回到那个位置。因为一旦跳出，堆栈就被破坏。
C 进入 Lua 的边界一共有四个 API：lua_call、lua_pcall、lua_resume、lua_yield 。其中要解决的关键问题在于调用一个 Lua 函数，却可能有两条返回路径。

Lua 函数的正常返回应该执行 lua_call 调用后面的 C 代码，而中途如果 yield 发生，会导致执行序回到前面 lua_resume 调用处的下一行 C 代码执行。
对于后一种，再次调用 lua_resume ，还需要回到 lua_call 之后完成后续的 C 执行逻辑。 C 语言是不允许这样做的，因为当初的 C 堆栈 已经不存在了。

Lua 5.2 改造了 API lua_callk 来解决这个问题。既然在yield 之后， C 的执行序无法回到 lua_callk 的下一行代码，那么就让 C 语言使用者自己提供一个 Continuation 函数 k 来继续。

我们可以这里理解 k 这个参数：当lua_callk 调用的 Lua 函数中没有发生yield 时，它会正常返回。一旦发生 yield，调用者要明白， C 代码无法正常延续，而 Lua VM 会在需要延续时调用 k 来完成后续工作。 k 会得到正确的 L 保存正确的 lua_State状态，看起来就好像用一个新的 C 执行序替代掉原来的 C 执行序一样。

一个容易理解的用法就是一个 C 函数调用的最后使用 lua_callk ：

lua_callk(L, 0, LUA_MULTRET, 0, k);return k(L);static int luaB_dofile (lua_State *L) {    const char *fname = luaL_optstring(L, 1, NULL);    lua_settop(L, 1);    if (luaL_loadfile(L, fname) != LUA_OK)    return lua_error(L);    lua_callk(L, 0, LUA_MULTRET, 0, dofilecont);    return dofilecont(L, 0, 0);}

也就是把 callk 后面的执行逻辑放在一个独立 C 函数 k中，分别在 callk 后调用它，或是 传递给框架，让框架在resume 后调用。这里 Lua 状态机的状态被正确保存在 L 中，而C 函数堆栈会被yield 后 被破坏掉。 如果我们需要在 k 中得到延续点前的 C 函数状态怎么办呢？ Lua 提供了lua_KContext ctx 用于辅助记录 C 中的状态。

Lua 的线程结构 L 中保存有完整的 CallInfo 调用栈。当 C 层面的调用栈被破坏时，尚未返回的 C 函数会 在 切入 Lua VM 前在 CallInfo 中留下延续点函数。原本在 C 层面利用原生代码和系统提供的 C 堆栈维系的 C 函数调用线索，被平坦化为 L 里 CallInfo 中的一个个延续点函数。想延续一个 C 调用栈被破坏掉的 Lua 线程，只需要依次调用 CallInfo 中的延续点函数就能完成同样的执行逻辑。

挂起与延续

理解了Lua 5.2 对线程挂起和延续的处理方式，再来看相关代码要容易理解一些。
中断并挂起一个线程和线程的执行发生异常，这两种情况对 Lua VM 的执行来说是类似的。都是利用 luaD_throw 回到最近的保护点。

不同的是，线程的状态不同。主动挂起需要调用 API lua_yieldk ，把当前执行处的函数保存到CallInfo 的 extra 中，并设置线程状态为 LUA_YIELD, 然后抛出异常。

和异常抛出不同，yield 只可能被lua_yieldk 触发，这是一个 C API，而不是 Lua VM 的指令。也就是说， yield 必然来源于某次 C 函数调用，从 luaD_call 或 luaD_pcall 中退出的。这比异常的发生点药少的多。

先看下 lua_yieldk 的实现。

LUA_API int lua_yieldk (lua_State *L, int nresults, lua_KContext ctx,                        lua_KFunction k) {    CallInfo *ci = L->ci;    luai_userstateyield(L, nresults);    lua_lock(L);    api_checknelems(L, nresults);    if (L->nny > 0) {        if (L != G(L)->mainthread)            luaG_runerror(L, "attempt to yield across a C-call boundary");        else            luaG_runerror(L, "attempt to yield from outside a coroutine");    }    L->status = LUA_YIELD;    ci->extra = savestack(L, ci->func);  /* save current 'func' */    if (isLua(ci)) {  /* inside a hook? */        api_check(k == NULL, "hooks cannot continue after yielding");    }    else {        if ((ci->u.c.k = k) != NULL)  /* is there a continuation? */            ci->u.c.ctx = ctx;  /* save context */        ci->func = L->top - nresults - 1;  /* protect stack below results */        luaD_throw(L, LUA_YIELD);    }    lua_assert(ci->callstatus & CIST_HOOKED);  /* must be inside a hook */    lua_unlock(L);    return 0;  /* return to 'luaD_hook' */}

不是所有的C 函数都可以正常恢复，只要调用层次上面有一个这样的 C 函数， yield 就无法正确工作。这是由 nny 的值来检测的。

lua_yieldk 函数是一个公开的API ，只用于给 Lua 程序编写 C 扩展模块使用。所以处于整个函数内部时，一定处于一个 C 函数调用中。但 钩子函数的运行是个例外。 HOOK 函数本身就是一个 C 函数，但是并不是通常正常的 C API 调用进来的。 在Lua 函数中触发钩子会认为当前状态是处于Lua 函数执行中。这个时候允许yield 线程，但无法正确的处理 C 层面的延续点，所以禁止传入延续点函数。而对于正常的 C 调用，允许修改延续点 k 来改变执行流程。这里只需要简单的把 k 和 ctx 设入 L ，其它的活都交给 resume 去处理就可以了。

lua_resume 的过程要复杂的多，先列出代码，再分析。

LUA_API int lua_resume (lua_State *L, lua_State *from, int nargs) {    int status;    int oldnny = L->nny;  /* save "number of non-yieldable" calls */    lua_lock(L);    luai_userstateresume(L, nargs);    L->nCcalls = (from) ? from->nCcalls + 1 : 1;    L->nny = 0;  /* allow yields */    api_checknelems(L, (L->status == LUA_OK) ? nargs + 1 : nargs);    status = luaD_rawrunprotected(L, resume, L->top - nargs);    if (status == -1)  /* error calling 'lua_resume'? */        status = LUA_ERRRUN;    else {  /* continue running after recoverable errors */        while (errorstatus(status) && recover(L, status)) {            /* unroll continuation */            status = luaD_rawrunprotected(L, unroll, &status);        }        if (errorstatus(status)) {  /* unrecoverable error? */            L->status = cast_byte(status);  /* mark thread as 'dead' */            seterrorobj(L, status, L->top);  /* push error message */            L->ci->top = L->top;        }        else lua_assert(status == L->status);  /* normal end or yield */    }    L->nny = oldnny;  /* restore 'nny' */    L->nCcalls--;    lua_assert(L->nCcalls == ((from) ? from->nCcalls : 0));    lua_unlock(L);    return status;}

lua_resume 开始运行时，等价于一次保护性调用。所以它是允许直接调用的 C 函数 yield 的。这里把 nny 设置为 0 开启。然后利用对 resume 函数的保护调用来进行前半段工作。

static void resume (lua_State *L, void *ud) {    int nCcalls = L->nCcalls;    StkId firstArg = cast(StkId, ud);    CallInfo *ci = L->ci;    if (nCcalls >= LUAI_MAXCCALLS)        resume_error(L, "C stack overflow", firstArg);    if (L->status == LUA_OK) {  /* may be starting a coroutine */        if (ci != &L->base_ci)  /* not in base level? */            resume_error(L, "cannot resume non-suspended coroutine", firstArg);        /* coroutine is in base level; start running it */        if (!luaD_precall(L, firstArg - 1, LUA_MULTRET))  /* Lua function? */            luaV_execute(L);  /* call it */    }    else if (L->status != LUA_YIELD)        resume_error(L, "cannot resume dead coroutine", firstArg);    else {  /* resuming from previous yield */        L->status = LUA_OK;  /* mark that it is running (again) */        ci->func = restorestack(L, ci->extra);        if (isLua(ci))  /* yielded inside a hook? */            luaV_execute(L);  /* just continue running Lua code */        else {  /* 'common' yield */            if (ci->u.c.k != NULL) {  /* does it have a continuation function? */                int n;                lua_unlock(L);                n = (*ci->u.c.k)(L, LUA_YIELD, ci->u.c.ctx); /* call continuation */                lua_lock(L);                api_checknelems(L, n);                firstArg = L->top - n;  /* yield results come from continuation */            }            luaD_poscall(L, firstArg);  /* finish 'luaD_precall' */        }        unroll(L, NULL);  /* run continuation */    }    lua_assert(nCcalls == L->nCcalls);}

如果 resume 是重新启动一个函数，那么只需要按和 luaD_call 相同的正常的调用流程进行。

若需要延续之前的调用，如上文所述，之前只可能从一次 C 调用中触发 lua_yieldk 挂起。但钩子函数是一个特殊情况，它是一个 C 函数，却看起来在 Lua 中。这时从 CallInfo 中的 extra 取出上次运行到的函数，可以识别出这个情况。

当它是一个 Lua 调用，那么必然是从钩子函数中切出的，不会有被打断的 Lua VM 指令，直接通过 lua_exwcute 函数继续它的字节码解析执行流程。若是 C 函数，按照延续点的约定，调用延续点 k，之后经过 luaD_poscall 完成这次调用。

上述事情做完之后，不一定完成了所有的工作。这是因为之前完整的调用层次，包含在 L 的 CallInfo中， 而不是存在于当前的 C 调用栈上。如果检查到 Lua 的调用栈上有未尽的工作，必须完成它。这项工作可通过 unroll 函数完成。

static void unroll (lua_State *L, void *ud) {    if (ud != NULL)  /* error status? */        finishCcall(L, *(int *)ud);  /* finish 'lua_pcallk' callee */    while (L->ci != &L->base_ci) {  /* something in the stack */        if (!isLua(L->ci))  /* C function? */            finishCcall(L, LUA_YIELD);  /* complete its execution */        else {  /* Lua function */            luaV_finishOp(L);  /* finish interrupted instruction */            luaV_execute(L);  /* execute down to higher C 'boundary' */        }    }}

unroll 发现 L 中的当前函数如果是一个 Lua 函数时，由于字节码的解析过程也可能因为触发元方法等情况调用 luaD_call 而从中间中断。故需要先调用 luaV_finishOp 函数，再交给 luaV_execute 函数开启 VM 来执行未完成的字节码。

当执行流中断于一次 C 函数调用，finishCcall 函数能完成当初执行了一半的 C 函数的 剩余工作。

static void finishCcall (lua_State *L, int status) {    CallInfo *ci = L->ci;    int n;    /* must have a continuation and must be able to call it */    lua_assert(ci->u.c.k != NULL && L->nny == 0);    /* error status can only happen in a protected call */    lua_assert((ci->callstatus & CIST_YPCALL) || status == LUA_YIELD);    if (ci->callstatus & CIST_YPCALL) {  /* was inside a pcall? */        ci->callstatus &= ~CIST_YPCALL;  /* finish 'lua_pcall' */        L->errfunc = ci->u.c.old_errfunc;    }    /* finish 'lua_callk'/'lua_pcall'; CIST_YPCALL and 'errfunc' already     handled */    adjustresults(L, ci->nresults);    /* call continuation function */    lua_unlock(L);    n = (*ci->u.c.k)(L, status, ci->u.c.ctx);    lua_lock(L);    api_checknelems(L, n);    /* finish 'luaD_precall' */    luaD_poscall(L, L->top - n);}

前面曾提到过，此时线程一定处于健康的状态。那么之前的工作肯定终止于 lua_callk 或 lua_pcallk。这时，应该先完成 lua_callk 没完成的工作（lua_callk 和 lua_pcallk 在调用完 luaD_call 后，后续的代码没有区别，都是 adjustresults(L, ci->nresults); 可以一致对待）； 然后调用 C 函数中设置的延续点函数； 由于这时一次未完成的 C 函数调用，那么一定来源于一次被中断的 luaD_precall， 收尾的工作还剩下 luaD_poscall(L, L->top - n);

当 resume 这前半段工作完成，结果要么是一切顺利，状态码为 LUA_OK 结束或是 LUA_YIELD 主动挂起。那么就没有太多剩下的工作。L 的状态是完全正常的。可当代码中有错误发生时，问题就复杂一些。

从定义上说，lua_resume 函数需要具有捕获错误的能力。同样有这个能力的还有 lua_pcallk。如果在调用栈上，有 lua_pcallk 优先于它捕获错误，那么执行流应该交到 lua_pcallk 之后，也就是 lua_pcallk 设置的延续点函数（）。

对 lua_resume 函数来说，错误被 lua_pcallk 捕获了，程序应该继续运行。它就有责任完成延续点的约定。这是用 recover 和 unroll 函数完成的。

static int recover (lua_State *L, int status) {    StkId oldtop;    CallInfo *ci = findpcall(L);    if (ci == NULL) return 0;  /* no recovery point */    /* "finish" luaD_pcall */    oldtop = restorestack(L, ci->extra);    luaF_close(L, oldtop);    seterrorobj(L, status, oldtop);    L->ci = ci;    L->allowhook = getoah(ci->callstatus);  /* restore original 'allowhook' */    L->nny = 0;  /* should be zero to be yieldable */    luaD_shrinkstack(L);    L->errfunc = ci->u.c.old_errfunc;    return 1;  /* continue running the coroutine */}

recover 函数用来把错误引导到调用栈上 最近的 lua_pcallk 的延续点上。
首先回溯CallInfo 栈，找到从 C 中调用 lua_pcallk 的位置。这次 lua_pcallk 一定从luaD_pcall 中被打断。

接下来就必须完成 luaD_pcall 本应该完成却没有机会去做的事情。所以 我们会看到，接下来的代码和 luaD_pcall 的后半部分非常相似。

最后需要把线程运行状态设上 CIST_STAT 标记让 unroll函数正确的设置线程状态。 然后只需要保护性调用unroll 函数来依据 Lua 调用栈执行逻辑上后续的流程。

回到 lua_resume 函数，其中的参数 from ，它是用来更准确的统计 C 调用栈的层级的。 nCcalls 的意义在于当发生无穷递归后，Lua VM 可以先于 C 层面的堆栈溢出导致的毁灭性错误之前，捕获到这种情况，完全的抛出异常。 由于现在可以 在 C 函数中切出，那么发起resume 的位置可能处于 逻辑上调用层次较深的位置。 这就需要调用者出入resume 的调用来源线程，正确的计算 NCcalls。

lua_callk 和 lua_pcallk

有了上面的基础，公开 API lua_callk 和 lua_pcallk 函数就能理解清楚了。

lua_callk 只是对 luaD_call 的简单封装。 在调用之前，根据需要把延续点 k 以及 ctx 设置到当前的 CallInfo 结构中。

LUA_API void lua_callk (lua_State *L, int nargs, int nresults,                        lua_KContext ctx, lua_KFunction k) {    StkId func;    lua_lock(L);    api_check(k == NULL || !isLua(L->ci),              "cannot use continuations inside hooks");    api_checknelems(L, nargs+1);    api_check(L->status == LUA_OK, "cannot do calls on non-normal thread");    checkresults(L, nargs, nresults);    func = L->top - (nargs+1);    if (k != NULL && L->nny == 0) {  /* need to prepare continuation? */        L->ci->u.c.k = k;  /* save continuation */        L->ci->u.c.ctx = ctx;  /* save context */        luaD_call(L, func, nresults, 1);  /* do the call */    }    else  /* no continuation or no yieldable */        luaD_call(L, func, nresults, 0);  /* just do the call */    adjustresults(L, nresults);    lua_unlock(L);}

lua_pcallk 函数 类似，只是对 luaD_pcall 的简单封装。
如果不需要延续点的支持或是处于不能被挂起的状态，那么 ，简单的调用 luaD_pcall 函数就可以。否则不能设置保护点，而改在调用前设置好延续点以及 ctx，并将线程状态标记为 CIST_YPCALL。这样在resume 过程中被 recover函数找到。

LUA_API int lua_pcallk (lua_State *L, int nargs, int nresults, int errfunc,                        lua_KContext ctx, lua_KFunction k) {    struct CallS c;    int status;    ptrdiff_t func;    lua_lock(L);    api_check(k == NULL || !isLua(L->ci),              "cannot use continuations inside hooks");    api_checknelems(L, nargs+1);    api_check(L->status == LUA_OK, "cannot do calls on non-normal thread");    checkresults(L, nargs, nresults);    if (errfunc == 0)        func = 0;    else {        StkId o = index2addr(L, errfunc);        api_checkstackindex(errfunc, o);        func = savestack(L, o);    }    c.func = L->top - (nargs+1);  /* function to be called */    if (k == NULL || L->nny > 0) {  /* no continuation or no yieldable? */        c.nresults = nresults;  /* do a 'conventional' protected call */        status = luaD_pcall(L, f_call, &c, savestack(L, c.func), func);    }    else {  /* prepare continuation (call is already protected by 'resume') */        CallInfo *ci = L->ci;        ci->u.c.k = k;  /* save continuation */        ci->u.c.ctx = ctx;  /* save context */        /* save information for error recovery */        ci->extra = savestack(L, c.func);        ci->u.c.old_errfunc = L->errfunc;        L->errfunc = func;        setoah(ci->callstatus, L->allowhook);  /* save value of 'allowhook' */        ci->callstatus |= CIST_YPCALL;  /* function can do error recovery */        luaD_call(L, c.func, nresults, 1);  /* do the call */        ci->callstatus &= ~CIST_YPCALL;        L->errfunc = ci->u.c.old_errfunc;        status = LUA_OK;  /* if it is here, there were no errors */    }    adjustresults(L, nresults);    lua_unlock(L);    return status;}

异常处理

Lua 的内部运行期异常，即错误码为 LUA_ERRRUN的那个，都是直接或间接的由 luaG_errormsg 函数抛出的。

按Lua 的约定，这类异常会在数据栈上留下错误信息，或是调用一个用户定义的错误处理函数。

l_noret luaG_errormsg (lua_State *L) {    if (L->errfunc != 0) {  /* is there an error handling function? */        StkId errfunc = restorestack(L, L->errfunc);        setobjs2s(L, L->top, L->top - 1);  /* move argument */        setobjs2s(L, L->top - 1, errfunc);  /* push function */        L->top++;  /* assume EXTRA_STACK */        luaD_call(L, L->top - 2, 1, 0);  /* call it */    }    luaD_throw(L, LUA_ERRRUN);}

它尝试从 L中读出 errfunc , 并使用 luaD_call 函数调用它。 如果在 errfunc 里再次出错，会继续调用自己。这样就有可能在错误处理函数中递归下去。但调用达到一定层次后， nCcalls 会超过上限最终产生一个 LUA_ERRERR 终止这个过程。

公开的API lua_error 函数 是对它的简单封装。

LUALIB_API int luaL_error (lua_State *L, const char *fmt, ...) {    va_list argp;    va_start(argp, fmt);    luaL_where(L, 1);    lua_pushvfstring(L, fmt, argp);    va_end(argp);    lua_concat(L, 2);    return lua_error(L);}