Re: How Lua code can be updated at runtime without breaking global state?

[William Ahern <william@...>]

On Tue, Mar 26, 2013 at 08:46:59AM +0400, Nikolay Zapolnov wrote:
> Hi, List!
> 
> On Tue, Mar 26, 2013 at 8:36 AM, Sean Conner <sean@conman.org> wrote:
<snip>
> >   It depends on the program.  I know I have one daemon [1] that allows the
> > Lua code to be updated on the fly, and I explicitely check the "global"
> > variables to see if they exist, and if not, create them.  The code tends to
> > look like [2]:
> >
> >         if blocked == nil then
> >           blocked = {}
> >           setmetatable(blocked,{ __index = function(t,k) return 0 end })
> >           os.execute("iptables --table filter -F INPUT")
> >         end
> >
> >   I doubt there's a "one-size-fits-all" solution here.
> >
> >   -spc (Or rather, I haven't bothered to look for one)
<snip>>
> The task is simple if you write your Lua code with some limitations in mind
> (i.e. do not re-initialize global state).
> 
> But the question is to how to make it work with any lua program...
> Because if you write an IDE like the Celedev you can not make any
> assumptions about the code.

It's simply not possible to make it work with _any_ Lua program. I suspect
the problem is equivalent to the Halting Problem.

The task, rather, is how to best mitigate the most common problems.

> I was wondering maybe there are some libraries (or at least a description
> of techniques) that allow such dynamic update of Lua programs.
> Maybe there is some "hack" in the Lua VM that allows to update only
> bytecode but do not touch global state?

The comments in this thread so-far are really good stuff. I might add that
module loaders could interpose an environment (_ENV or function
environments) to capture globals. I think this technique was implied, for
the most part. And all the discussion about upvalues is because there's no
easy way to capture loads and stores to upvalues in order to prevent a
module from reinitializing its long-term state.