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

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);
}