lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Just to raise another issue (yet again).

This would be an excellent time to settle on some 'standard' names for Lua .dll/.so files, so that modules might actually be compatible.....

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software

----- Original Message ----- From: "D Burgess" <>
To: "Lua list" <>
Sent: Monday, June 07, 2004 8:42 AM
Subject: Re: More about packaging (fwd)

I concur with Edgars comments.

However, it seems that this minor issue has hijacked Diegos
original agenda, namely; the best way to manage (and mask) the
difference between static and dynamically loaded libraries.

Unload support would be a nice addition but is not critical.

The original question was in

David B

Edgar Toernig <> wrote:

Mike Pall wrote:

- An extensive framework to support automatic unloading is very difficult
  to get right and will not benefit most developers.

Sorry?  2-5 lines of code in the Lua core plus the dlclose handling in
the loader library.  That's all!

- There is no way we can prevent everyone from shooting themselves in the
  foot. There are far more loopholes than we could possibly close.

Hmm?  Afaik, any way to crash the app from a Lua script is considered
a serious bug.

The current solution already passes a handle to the library as an upvalue to the function loaded from the library. So this function has the ability to provide support for unloading. It's just that no libraries I know of do
that. Maybe because it's undocumented?

A library cannot unload itself.  The code to perform that has to be
in another segment, else the dlclose call returns to just unmapped
memory.  Beside that, you would require system dependant code in
each library.

And about the danger of crashing Lua: If you can use loadlib(), you can
always provoke a crash by referencing an innocent symbol:
  loadlib("", "read")() -> Segmentation fault

That's only because of the trivial loadlib implementation.  A sane
version would perform checks similar to those in the precompiled-
script loader.  I.e. in my implementation, every dynamically loaded
binary has a structure with a fixed name in the .so that describes
the library: version info, number size and type, start function.
That data is checked and only if everything's ok, the cclosure of
the start function is returned.

Ciao, ET.