lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



On Dec 17, 2008, at 1:24 AM, Sam Roberts wrote:
On Sun, Dec 7, 2008 at 12:32 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
When C is called from lua, it must use the L it was passed. If C calls
back into lua, after lua returns to it, it must use the L it was
originally passed. Still. Even if lua had called back into C. This may not be easy to arrange, and until coroutines are used creatively, bugs
may never be seen.

What was the question?

I wonder if there's a canonical way to avoid these problems, perhaps
involving lua_newthread.

I've never seen any, and more threads are likely to make more of a problem.

In lsqlite3, http://luaforge.net/projects/luasqlite/ -- which is not the subject of this thread (to overload that word even further), but which implements the same glue as the discussed wrapper lua-sqlite3, we use the following approach:

When the database's userdata handle is created we record the caller's L in the database's userdata handle.

When a Lua function (user function, busy handler, progress handler, trace callback) is provided to SQLite it is provided in the context of a database handle; that associated database handle is recorded in the function's userdata handle. The function's userdata handle is the (void *) data we give SQLite along with our C callback wrapper function.

When a callback is executed SQLite gives us the function's userdata handle we provided; that is used to get the associated database's userdata handle, and it's L is used to execute (lua_pcall) the Lua function.

So, the rule is: as long as the Lua thread that created the database handle remains active, the callback can be used from any Lua thread.

e