Re: status and perceptions of luaproc

[Patrick Donnelly <batrick@...>]

On Sat, Aug 8, 2015 at 12:42 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> Am 08.08.2015 um 18:02 schröbte Patrick Donnelly:
>>
>> On Fri, Aug 7, 2015 at 5:00 PM, Rena <hyperhacker@gmail.com> wrote:
>>>
>>>
>>> On Aug 7, 2015 3:42 PM, "William Ahern" <william@25thandclement.com>
>>> wrote:
>>>>
>>>>
>>>>    If you were to design a new language today, he said, you would make
>>>> it
>>>>    without mutable (changeable) objects, or with limited mutability.
>>>>
>>>>    -- Guido on Python, discussing the GIL. See
>>>> https://lwn.net/Articles/651967/
>>>>
>>>
>>> Well, that's pretty convincing. Though I still feel like Lua could
>>> benefit from a "copy string from other state" function that can avoid the
>>> duplication and rehashing. (Does POSIX provide a thread-safe
>>> reference-counted memory block API?) Same for tables and functions, assuming
>>> it could be done any more efficiently on the "inside" compared to using the
>>> public APIs. Faster/less wasteful passing of objects (especially strings)
>>> between independent states within a process would be quite helpful for
>>> message passing.
>>
>>
>> <tangent>
>> Something I'd like to see is the ability to represent memory mappings
>> as strings in a Lua state. Obviously creating a mapping is possible
>> with libraries like luaposix or LuaJIT's FFI, but what is really
>> missing is a way to *use* those mappings as regular Lua strings. And
>> when I say "as regular Lua strings", I mean from a library perspective
>> (like the string library). [After all, Lua strings are just blobs of
>> data you can create via literals and/or concat operations. Without
>> libraries like io/string, they have have no real function or utility.]
>>
>> Using memory mappings like strings in Python (for some APIs) is one of
>> the few things I like about that language. If we could provide a
>> similar API (read: metamethod) for converting an object to a <light
>> userdata pointer, length> tuple usable wherever a string is desired,
>> then we could see the same thing in Lua. [Of course, note that
>> lua_touserdata is not what we need since a memory mapping is not
>> managed by the Lua allocator.] I see lua_tostring as the right API to
>> abstract the conversion.
>> </tangent>
>
>
> Lua strings are immutable, a memory mapping can change behind your back, so
> you can't use those "strings" as table keys, you can't cache hash values,
> any you might get inconsistent data if you process those "strings"
> piece-wise.

You're quite right but I don't see that as a problem. The memory
mappings are still userdata (and can be used in tables normally) but
are convertible to Lua strings in C library code.

-- 
Patrick Donnelly