Re: Thread-support in LUA

[Roberto Ierusalimschy <roberto@...>]

> Do you have an idea when you might be releasing v3.1 of Lua?  Can
> you describe what exactly you intend to implement in 3.1 to address
> the "thread" issues discussed here?

I think there was a misundertanding here. What was told in the other message
was that Lua 3.1 was going to support "closures", that is, nested functions
with proper lexical scope; check below:

> >A "psudo-overlapping" desire of mine is to
> >have first-class function definetions (like lambda functions, in that you
> >would do something like "boo = function(a,b) ... end". When I brought this
> >up before, it was said that the parser needs to be made reenterant for
> >this to work, so I was hoping to combine my efforts for these two things.
> 
> We currently are working on exactly this extension for Lua 3.1.
> Keep tuned. :-)

  Lua 3.1 also is going through a lot of "reengineering", for better
modularity, clarity of source code, etc. But it is not our goal now to
support multiple environments and/or threads.

  Multiple environments can be simulated by a proper manipulation of the global
variables. From a Lua point of view (not from C), the only global state are
the global variables. You can save all global variables in a table and later
restore those variables. In this way, you have a rather good approximation of
multiple environments.

(for instance, to save an environment, you can use:

function save ()
  local env = {}
  local n, v = nextvar(nil)
  while n do
    env[n] = v
    n, v = nextvar(n)
  end
  return env
end
)

  Multiple threads is a complete different story, as already pointed out.
Even if you flatten Lua calls in the Lua stack, as Bret Mogilefsky has done,
you still do not have a general solution, since you can not mix in calls
to C that calls back Lua (like dostring, dofile, gsub, etc). Please don't get
me wrong: Bret's solution seems like an excelent piece of software. But
to be part of the language it should be a complete general and portable
solution. It seems to us that a general solution would need threads in C,
too (or at least co-rotines, that is, multiple stacks), and there is no
portable (in an ANSI universe, not only POSIX) way of doing that.

-- Roberto