[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: More about packaging (fwd)
- From: "D Burgess" <db@...>
- Date: Mon, 7 Jun 2004 9:12:31 +1000
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
Edgar Toernig <firstname.lastname@example.org> 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
>> And about the danger of crashing Lua: If you can use loadlib(), you can
>> always provoke a crash by referencing an innocent symbol:
>> loadlib("libc.so.6", "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.