Re: question for lua-COCO implementation

[Mike Pall <mikelu-1004@...>]

takehiro iyatomi wrote:
> but one problem, luajit 2.0.0 does not support lua_dump.
> (I guess the reason is after JIT compiled, original lua byte code discarded)

It's simply not implemented (yet).

> because I want to enable the RPC which argument contains function object,
> lua_dump is necessary to provide such a feature.
> it there any plan to support lua_dump on luajit?

See: http://lua-users.org/lists/lua-l/2010-03/msg00064.html

As for your use case: copying Lua code with lua_dump to a remote
node and loading it into the remote Lua VM is very expensive (for
both ends). So you certainly have implemented a kind of binding
mechanism to avoid doing this on every remote call?

Then it should be relatively easy to pass a reference to the code
during the RPC bind. So for
  local foo_bar = rpcbind(node, "foo.bar")
the remote node would look up the function "bar" in the module
"foo". In case the remote doesn't have module "foo", you could
just pass the source code along (and cache it on the remote).
It'll give you back a handle you can use later in the local
wrapper function returned from rpcbind().

Overall this mechanism will be faster and less error-prone than
dumping/loading bytecode. Functions with upvalues are problematic
as their contents are not dumped. E.g. you wouldn't be able to
successfully send and run this function on the remote:

  local bit = require("bit")
  function foo(x)
    return bit.bnot(x) -- 'bit' is an upvalue here, will be nil on remote!
  end

Sending bytecode around is one of those ideas that sound really
nice in theory, but actually cause a lot of problems in practice.
I would try to avoid it.

--Mike