[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Serializing Lua functions (was Re: status and perceptions of luaproc)
- From: Sean Conner <sean@...>
- Date: Fri, 7 Aug 2015 18:38:03 -0400
It was thus said that the Great Rena once stated:
>
> The thread libraries I've used run a separate Lua state in each thread and
> provide some type of communication channel between them. This is a nice
> simple model, but maybe not the most efficient. In particular, while it's
> usually possible to pass most types of Lua objects between threads, tables
> can only be recursively copied, functions have to be dumped and recompiled
> (and can't have upvalues), and userdata can't safely be passed around
> unless it's designed to be referenced by multiple Lua states.
Actually, you can serialize Lua functions with upvalues. I've done it
(just not shown the code). In fact, I was able to serialize quite a bit,
including tables with circular references. The only things I couldn't
handle were coroutines, user data and Lua functions written in C [1].
As it stands, the function serialization is only good across the same
architecture (everything else I could serialize was CPU independent) and I
started working on fixing that by diving into the "dump format" used by Lua.
-spc (I kind of lost interest when I realized I didn't have a need for
this)
[1] At least not directly. I could "serialize" the function io.write(),
but I did so by reference, assuming the receiver side could resolve
such a reference. I could even handle known userdata types like
io.stdout by again, using references. [2]
[2] Strings basically. I just passed the name along.