[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [Proposal-ish?] Lua should bind the Lua C API as a Lua module
- From: Xavier Wang <weasley.wx@...>
- Date: Wed, 29 Nov 2017 22:29:41 +0800
2017-11-28 9:27 GMT+08:00 Soni "They/Them" L. <email@example.com>:
> Reading material:
> Some game developers would significantly benefit from a slightly
> stripped-down 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.)
>  - 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 several years ago.