Re: Running multiple threads in a lua state

[Coroutines <coroutines@...>]

Thanks, I'll have a look! ^__^  memcpy() was a big of an exaggeration on my part, I kept envisioning some way to isolate a set of lua objects together in one state, then copy them out as a sort of packed userdata to load them into the other state (and unpack there).

On Sat, Apr 5, 2014 at 9:57 AM, Rena <hyperhacker@gmail.com> wrote:

On Fri, Apr 4, 2014 at 8:19 PM, Sean Conner <sean@conman.org> wrote:

It was thus said that the Great Coroutines once stated:
>

> I do agree that separate global_States in separate threads is the
> safer/saner way to go.  The issue I have with that is swallowing the cost
> of marshalling/serialization.  I wish there were a lua_xmove() for moving
> objects between global_States, so you could make all "Lua instances"
> visible within a shared memory space, and swap objects directly between
> them.

  I don't know.  I want to say that if you want to move an arbitrary object
between threads you are doing it wrong, but I'm not sure what you are trying
to do, so I won't say that 8-P

  In general, it's a difficult, if not outright, impossible task.  Tables
are difficult, and I suspect userdata is all but impossible to handle
correctly with a "lua_gsxmove()" function.

  And as for the cost of marshalling/serialization, remember, the QNX X
server I'm talking about did all that, and *still* was faster than a shared
memory version of the server.

  -spc

I've actually implemented some functions that can copy nearly any value between Lua states: http://pastie.org/8996668

Interesting things to note about this code:

* It looks for a __xcopy metamethod to handle copying. That allows to handle most userdata.
  Directly copying the memory block would probably be a bad idea, but this method lets you

  push a new, identical object into the destination state, or a reference (if your userdata is a

  pointer to a reference-counted object like mine usually are when they might be copied to

  multiple states), or even just throw an error (but it'd make more sense to just not implement

  __xcopy at all in that case).

* It can copy any type except for Userdata (unless it has __xcopy) and Thread (as that makes

  no sense really). String copying is binary-safe (but maybe not terribly memory-efficient, since

  each Lua state will internally make a copy of the string). Tables are copied recursively (but

  there's nothing to prevent infinite recursion, so be careful of nested references). Functions can

  be copied, but they might not work as expected due to a lack of _ENV (this is something I

  still need to investigate and fix).

(I'm also not totally sure that "luax" is a safe prefix. I've seen that Lua uses some prefixes such as luaO and luaV internally.)

--
Sent from my Game Boy.