Re: [ANNOUNCE] Lua 5.0 (pre-release) now available

[Jay Carlson <nop@...>]

On Wed, 2 Apr 2003, Roberto Ierusalimschy wrote:

> > > Some platforms may not allow loaded objects to reference symbols in the
> > > main program at all; I think AIX is or was such a platform.
> >
> > As is Windows.
>
> I am not a Windows expert, but as far as I know, this is not completely
> true. In Linux (and I guess all Unix) there is no problem if a program
> uses multiple copies of the same code; equal code means equal results.
> So, there is no difference whether a loaded object shares the Lua code
> from the main program or loads its own copy.

Equal code means equal results if it also has equal data.  The ELF
runtime linker will try to make sure that there's only one symbol
named (say) "errno", but it will not merge static variables from two
different copies of the same code.

The particular nightmare scenario here is an application using an
interpreter (call it "Aul") which has some static variables used for
precomputing results.  Then the application loads an extension that
also has a copy of Aul linked in.  Everything behaves as if there was
a single copy of the functions except now there are two different
behaviors depending on which version of the function with static
variables you call.

This is a problem with Aul, but not with Lua, since Lua very carefully
keeps all of its state in one place.  Of course, other extensions may
not be so careful.

Actually, this can be less of a problem in practice than you might
think.  The same ELF runtime linker code that makes sure "errno"
points to only one place also makes sure "lua_settable" points to only
one place.  Unless you can figure out how to distinguish the two
copies of lua_settable (I forget if dlsym does that) you can't run
into the above problem.

Still, it seems prudent not to tempt fate even on the tolerant ELF
platforms, and on other systems you don't have as much wiggle room.

Jay (owner of a shared library ABI that makes HPUX look like
Smalltalk)