lua-users home
lua-l archive

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


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.