Re: Lua table in a shared memory segment

[Matthieu Tourne <matthieu.tourne@...>]

On Thu, May 31, 2012 at 9:37 PM, agentzh <agentzh@gmail.com> wrote:
> Hello!
>
> On Fri, Jun 1, 2012 at 3:39 AM, Javier Guerra Giraldez
> <javier@guerrag.com> wrote:
>> On Thu, May 31, 2012 at 2:24 PM, Matthieu Tourne
>> <matthieu.tourne@gmail.com> 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
multiple processes.