Re: [Proposal-ish?] Lua should bind the Lua C API as a Lua module

[Xavier Wang <weasley.wx@...>]

2017-11-28 9:27 GMT+08:00 Soni "They/Them" L. <fakedme@gmail.com>:
> Reading material:
> https://en.wikipedia.org/wiki/Operating-system-level_virtualization
> https://en.wikipedia.org/wiki/Protection_ring
>
> Some game developers would significantly benefit from a slightly
> stripped-down[1] Lua C API as a built-in Lua module, as it would give the
> ability to create perfectly-isolated sub-states from Lua.
>
> Because you'd be able to register (host) Lua functions as (guest) C
> functions, they'd appear as opaque C functions to the sub-states, which
> means the debug.* API could be trivially (and safely!) made available to
> them. For example:
>
> GUEST | call os.time()
> HOST | call guestostime()
> HOST | <operations to implement the guest's os.time()>
> HOST | return to guest
> GUEST | get result created by host
> GUEST | call debug.* functions against os.time, but get no useful results
> other than it being a C function.
>
> It is technically possible to implement this in pure-Lua as it currently
> stands, at a hefty amount of overhead, both in terms of code/maintenance
> overhead, and CPU time. (it basically involves reimplementing the debug.*
> API by checking if the given function is a valid target for the debug API,
> and carefully wrapping host functions so they look like C functions to the
> guest, and so on.)
>
> [1] - We don't want to expose luaL_newstate, we want lua_newstate to use the
> current state's allocator and stuff, and things like that.
>
> --
> Disclaimer: these emails may be made public at any given time, with or
> without reason. If you don't agree with this, DO NOT REPLY.
>
>

I have made this[1] several years ago.

[1]: https://gist.github.com/starwing/0e91c2898d3621d41f785f7d927b2b99

-- 
regards,
Xavier Wang.