[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Extending Lua-RPC: questions about handling index and call events
- From: James Snyder <jbsnyder@...>
- Date: Fri, 5 Jun 2009 09:48:16 -0500
On Jun 4, 2009, at 8:05 PM, Geoff Leyland wrote:
On 5/06/2009, at 2:39 AM, James Snyder wrote:
Hmm.. So, executing the line above gives you the following bytecode:
main <test.lua:0,0> (6 instructions, 24 bytes at 0x1dd5530)
0+ params, 2 slots, 0 upvalues, 0 locals, 4 constants, 0 functions
1  GETGLOBAL 0 -1 ; math
2  GETTABLE 0 0 -2 ; "cos"
3  GETGLOBAL 1 -3 ; handle
4  GETTABLE 1 1 -4 ; "some_remote_value"
5  CALL 0 2 1
6  RETURN 0 1
This is tougher than the other metatable stuff because after
getting the cos function onto the stack, locally, I'm putting a
some_remote_value userdata for it to operate on locally.
Unfortunately, it's not a lua number however, it's a userdata.
Looking at how this is implemented in lua, I don't see how I can
hook this in such a way that I can have that userdata behave like a
Sorry, I got that one wrong - I can see how
handle.math.cos(handle.some_remote_value) could be done in one round
trip to the server, but I agree that
math.cos(handle.some_remote_value) is not going to work and I can't
see a way around math.cos(rpc.get(handle.some_remote_value)). You'd
need some kind of c++ cast operator - maybe you could campaign for a
__tonumber metamethod in Lua 5.2?
That, I think, would be quite nice to have for this situation. I did
find this earlier discussion that suggests __tonumber (for different
reasons), and includes a patch that modifies luaB_tonumber to try
There are some upsides and downsides discussed there as well.
One idea that I have no idea whether it might work would be some way
of __index to be able to tell who is asking who is about to consume
the value. Such a mechanism could have interesting implications,
certainly including possibility for good and evil. I haven't really
investigated to see what one has available through debug hooks when
index is called, so this could be really messy or impossible :-)
Another way to do things would be to have index2adr optionally call a
metamethod. I don't know if this ever gets called early such that you
might accidentally do pro-active rather than lazy evaluation. Also,
I'm sure such a change would potentially slow down everything else in
There's some interesting stuff here too, although I don't think it
really solves the problem:
This, I suppose, is the crux of this issue: how do I know whether
to push userdata onto the local stack, or to serialize the remote
value and put that actual value on the stack instead?
handle.math.cos(handle.some_remote_value) wouldn't be as much of a
problem, since I could push over the index events to get
some_remote_value onto the remote stack for the remote cos.
I guess one way to deal with this would be to handle things this
way for remote indexes:
if type is number, string, boolean, or nil:
serialize it and put it on the local stack,
provide lazy evaluation helper
There are probably a bunch of disadvantages I'm not thinking of
here, but I think, for sure, I have to point the index to some sort
of proxying function that actually gets the remote value, otherwise
I'll end up with a local cached value on the local table (which
would be undesirable if the value changed on the remote side and I
wanted to poll it).
Does this mean you'd have to go and ask the server at each __index?
But then, "for k, v in pairs(handle.some_remote_table) do..."
wouldn't work either. (Campaign for __pairs in Lua 5.2?)
Hmm.. that would be true as well. I suppose another alternative would
be to serialize only tables that contain all serializable entries, but
I think that starts getting too weird and inconsistent.
Interesting, is Rima available somewhere? I might be interested
in taking a look just to see if I might learn a bit from the
Just ignore all the solver stuff and have a look at the symbolic
math stuff. rima/ref.lua is probably where the interesting stuff
happens. Rima does not do this nicely yet - it's more that I aim to
have it looking like what you're talking about one day.
Thanks. I will take a look. I do have some interest in symbolic math
stuff as well, though I don't end up using it a great deal in day-to-
I could see some advantage to doing something like what you
describe above where you might have a client talking to multiple
lua instances to either poll them for state information, or to do
work on them. If you wrap things with some sort of map function
and use it to work on large chunks of data over a series of
connections registered on a table or something.
I'm mainly working on this for use with eLua (hence the serial link
protocol being supported (which is giving me some headaches) ), so
that I can have a link to an embedded device and do development and
testing while having the benefit of being able to get large
quantities of data back to a desktop machine. There might be
benefit to being able to use this sort of thing to poll a bunch of
embedded devices in succession over a network or wireless link.
Distributing workloads seems like an obvious use?
Perhaps someone will take a look at it for uses like that at some
point. There are certainly already some models out there for
concurrency in Lua. I know the serialization and protocol here aren't
necessarily new, but being able to manipulate other Lua environments
as if they were a table seems like a powerful metaphor.
At least the path for doing this with functions seems fairly
ph: (847) 448-0386
Description: This is a digitally signed message part