[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: About the Lua core
- From: "Soni \"They/Them\" L." <fakedme@...>
- Date: Sat, 15 May 2021 14:09:20 -0300
On 2021-05-15 3:29 a.m., Stefan Ginsberg wrote:
> Lua 5.4 lists a change in "Incompatibilities in the API" for
> 'lua_version' that "The Lua core should work correctly with libraries
> using their own static copies of the same core, so there is no need to
> check whether they are using the same address space.".
> This is also documented in some commits to the codebase.
> What is the intention behind this and what does it actually enable?
> Under what circumstance would one need to share a state (L) between
> different instances of the same Lua library? Would such separation of
> instances not mean a separation of the states to begin with?
> Also are there other benefits to having Lua states without global
> memory in them (such as luaO_nilobject) which was what enabled this
Oh cool, hadn't noticed that before!
One questionable benefit of not having such global state is that
corrupting one state shouldn't lead to corruption of other states. But
if you have such memory corruption issues, the global state is likely
the least of your worries... One other benefit tho is being able to
throw Lua in a dlmopen(3) and share Lua states with it - it would be
really hard otherwise.
One drawback is that memory usage per state may go up slightly. But it's
probably okay for most use-cases.