Re: status and perceptions of luaproc

[Patrick Donnelly <batrick@...>]

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>

-- 
Patrick Donnelly