 |
lua-l archive |
|
|
||
|
It was thus said that the Great Coroutines once stated:
> On Fri, Apr 4, 2014 at 8:44 AM, Luiz Henrique de Figueiredo <
> lhf@tecgraf.puc-rio.br> wrote:
>
> > > You'd think that read-only access to the a shared global_State from
> > > different lua_State's (coroutines.create()) would be possible without a
> > > global interpreter lock.
> >
> > You'd think that, yes, but as soon as you try it you'll see there are
> > problems. Consider
> > lua_getglobal(L,"myvar")
> > Is that a read-only access to L? It seems so but it may not be if "myvar"
> > is not in the string table. The implementation of lua_getglobal finds
> > "myvar" in the string table by actually adding it to the string table.
> > (In the current version of Lua this only ends up actually adding the var
> > name to the string table if the var name is longer than 40, but that is
> > an implementation detail.)
> >
> >
> That is a subtle "gotcha"... I still wonder what you can get away with if
> you're making sure you modify unrelated areas of the global_State without
> locks.
How can you be sure that two threads aren't mucking with the same area of
the global state? Even if there's a one-in-a-billion chance of that
happening, that will take what? All of a few seconds for that to happen
with today's machines?
I agree with Javier Giraldez, keep the lua states separate and share data
via message passing. It's the only way to keep sane [1].
-spc
[1] And oddly enough, performance. Back in the mid-90s, some friends of
mine worked at a company that produced commercial X servers. Their
fastest version ran on QNX [2], a purely message passing based
operating system. Even the X servers that used shared memory were
slower than their QNX version.
[2] A message-based real-time microkernel. At the user level, it looked
like Unix, but underneath, it was incredible. A very small kernel
(about 8K on a Pentium) and everything else (file systems, device
drivers, hell, even some standard libraries) were implenented as
user processes. Nothing quit like running a program on machine A,
redirecting input from a file on machine B, piping the output to
another program on machine C while the command was typed on machine
D. [3]
[3] I worked briefly at a company that did QNX related work. My boss
would regularly use the modem on my machine from his machine across
the hall. It was invisible to the program that the modem was not
local.