[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua table in a shared memory segment
- From: Matthieu Tourne <matthieu.tourne@...>
- Date: Sun, 3 Jun 2012 01:33:49 -0700
On Thu, May 31, 2012 at 9:37 PM, agentzh <firstname.lastname@example.org> wrote:
> On Fri, Jun 1, 2012 at 3:39 AM, Javier Guerra Giraldez
> <email@example.com> wrote:
>> On Thu, May 31, 2012 at 2:24 PM, Matthieu Tourne
>> <firstname.lastname@example.org> wrote:
>>> But fundamentally a key value store is different than a table, and
>>> can't store nested tables for instance.
>> that's a limitation of the underlying rbtree, not of Lua.
>> specifically, that it only stores strings and numbers.
> And booleans too (but nothing else) :)
>>> Would it be possible to memcpy the entire representation of Lua table
>>> and store it in shared memory ?
>> no. complex structures full of pointers don't survive a naive memcpy.
>> you'd need some serialization step.
> Agreed :)
> And it all boils down to the requirement for really fast serialization
> and de-serialization methods :)
The problem with serializing is that for an algorithm that runs in
log(n) over a tree (made with nested Lua tables), you'll have to
de-serialize the whole structure of n-nodes before.
Maybe it's possible to represent a Lua table with the underlying
C-structure (b-tree here), which would allow nested structures. With
no need for deserializing when reading!
But there can't be references to external objects like in a full
table, since this lives in a shared memory segment and can be used by