Re: 5.2: debug.upvalueid & debug.upvaluejoin? + kinda [ANN]
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: 5.2: debug.upvalueid & debug.upvaluejoin? + kinda [ANN]
- From: GrayFace <sergroj@...>
- Date: 2010年1月15日 05:28:11 +0600
Very useful functions. I've made a patch for Lua 5.1 with them (tested
on 5.1.4). For now it's here:
http://sites.google.com/site/sergroj/news/upvaluejoin.rar?attredirects=0&d=1
Here's a small description of what debug.upvaluejoin does:
upvaluejoin(f1, n1, f2, n2) makes f1 use upvalue #n2 of f2 as its #n1
upvalue. So, now you can easily persist Lua functions that share some
upvalues.
Note that the order of argumants matters:
upvaluejoin(f2, n2, f1, n1); upvaluejoin(f3, n3, f2, n2); will make
f1, f2 and f3 all use the same upvalue.
upvaluejoin(f1, n1, f2, n2); upvaluejoin(f2, n2, f3, n3); will make f2
and f3 use the same upvalue, while f1 will use upvalue previously used
by f2.
You can think of it as an assignment: f2[n2] = f1[n1]; f3[n3] = f2[n2];
isn't the same as f1[n1] = f2[n2]; f2[n2] = f3[n3];
debug.upvalueid is described in 5.2 manual.
However, I'm concerned about upvaluejoin implementation. It sets new
barrier for *up2, but doesn't make any reference changes to *up1. I
don't know how GC works, but this seems odd.
Here's the implementation:
LUA_API void lua_upvaluejoin (lua_State *L, int fidx1, int n1,
int fidx2, int n2) {
Closure *f1;
UpVal **up1 = getupvalref(L, fidx1, n1, &f1);
UpVal **up2 = getupvalref(L, fidx2, n2, NULL);
*up1 = *up2;
luaC_objbarrier(L, f1, *up2);
}