Packaging, 2 last concerns

[Diego Nehab <diego@...>]

Hi,

I think we are almost there. I have two issues to discuss. One of them
relates garbage collection of namespace tables, dynamic library unloading
and static vs. dynamic independent code. The other has to do with
namespace table cloning.

-- Garbage collection/dynamic vs. static/unloading

Static libraries and dynamic libraries are similar to Lua files that are
built into the executable or that lie somewhere in the file system.

If a library is static, either the loader entrypoint or a the resulting
namespace table has always to be available to the "require" function in
such a way that it won't try to load them from disk.  They can't be
collected, otherwise the library is lost forever.

On the other hand, if a library is dynamic and if we hope for it to be
unloaded, any reference to it *has* to be garbage collected. Otherwise,
anyone who tries to call the entrypoint or use the namespace table will
crash.

My idea of setting the _LOADED table from within the loader, which
allows the exact same code to be used for dynamic and static libraries,
doesn't help here.

Can anyone please point out the simple, elegant and obvious solution to
this problem? "Who cares?" is a good answer.

-- Namespace table cloning

Rici pointed out that, for sandboxes, it is important to clone a
library's namespace table so that scripts can mess up with it as much as
they want.

On first thought, both alternatives we have been considering fail
to offer a simple solution to this problem. Turns out that when a
library is loaded, it's implementation is bound to the original table or
the original environment that was active when the loader was run.

When you clone a namespace, the implementation still refers to the
original namespace. If you make changes to the cloned namespace (such as
changing a constant, or providing a new implementation for one of its
functions), the library's implementation will not see the changes.

Anyone has an obvious solution for this problem? Seems like a tough one,
especially because there might be local functions that are not even
visible from the namespace table.

Best regards,
Diego.