lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2017-11-28 9:27 GMT+08:00 Soni "They/Them" L. <>:
> Reading material:
> 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.


Xavier Wang.